Путь менеджера. Что вы сделали с вашей мечтой?

Иногда, глядя на деятельность менеджеров проектов приходишь в ужас! Любой проект - это мечта сделать мир лучше, сделать что-то грандиозное (я не беру в рассмотрение проекты с мечтой “бабло-бабло-бабло-машины-женщины-особняк”, люди руководящие такими проектами не менеджеры, а китайцы штампующие ширпотреб). Но мне очень часто приходится наблюдать печальную тенденцию: хорошо стартовавшая разработка, впоследствии перетекает в погоню за фитчами и преждевременную оптимизацию еще до первого официального выпуска в свет! По-моему, это те две вещи, которые могут на корню зарубить любую программную разработку, либо очень сильно затянуть выпуск и продвижение.

Ваш проект - ваш ребенок. Представление проекта заказчику- это как представление ребенка светскому обществу. Вы растили его, учили и теперь пришло время показать ваше чадо всем. Представьте званный ужин, пришло много семейных пар (компаний) со своими детьми (проектами), все обсуждают своих малюток и... ах да, чуть не забыл, ужин организован по поводу крестин ваших малюток, и во главе стола восседает ваш крестный отец (инвестор). Все стараются продемонстрировать, какие у них хороши детки, доходит очередь до вас, и тут начинается самое интересное: вы проводите вашу шестилетнюю малышку с бородой до фортепьяно, и они начинает играть “Лунную сонату”. Вы стоите рядом и улыбаетесь. Затем ваша девочка начинает играть в две руки и две ноги, опираясь на свои крылышки, которые, из-за недостатка времени, пришлось сделать из стальной арматуры и окрасить в белый цвет. Все взгляды уставлены на вас и ваше чадо, которое начинает фальшивить, т.к. ей мешает бюстгальтер с размером чашечки E. Ну и пусть что груди у нее еще нет, но вы как менеджер решили натянуть бюстгальтер заранее, потому что точно уверены - у вашего чада уже очень скоро появится шикарный бюст! Вы достаете из кармана пиджака три шарика и один эээ... кубик (на самом деле вы должны были достать четыре шарика, но один потерялся, и пришлось его заменить подручными средствами). К этому времени ваша девочка (хотя собравшиеся уже начинают сомневаться) освобождает руки, продолжая играть одними ножками (что получается крайне плохо, ведь у нее на ножках надеты ласты, т.к. менеджер посчитал, что возможно, вам понадобиться продемонстрировать ее умение плавать... топориком) и освободившимися ручками начинает жонглировать вашим “набором”. Когда сие представление закончилось, т.к. предметы жонглирования улетели в сторону гостей, вы кланяетесь и произносите “А еще она отлично бегает, плавает, вышивает крестиком и танцует вальс - кто хочет потанцевать с ней?”, а все присутствующие в этот момент вжались в стулья и трясутся от страха.

Скажете у меня извращенная фантазия? Да нет... именно так ведут себя большинство менеджеров проектов, считая, что заказчику будет мало одной функции, и начинается погоня за фитчи, что влечет за собой смещение сроков выпуск продукта. Если заказчик сказал, что было бы не плохо, чтобы в процессе работы вашей программы варилось кофе - это не значит, что варить кофе должна ваша программа. Сделайте ему программу и подарите кофеварку.

Фитчи - это код, а код содержит баги. И чем больше кода, тем больше багов и тем хуже качество продукта. Выпустите продукт, который делает одну вещь, но делает ее хорошо. Покажите ее заказчику, продайте ему, а затем преступайте к добавлению следующий фитчи. Такой методологии придерживаются 37 signals, такой методологии придерживаюсь я и настоятельно рекомендую посмотреть в этом направлении и вам. Не число фитч делает продукт успешным, а их качество (и продажники).

Когда Google вышел на мировой рынок, у него был только поиск, простой текстовый поиск. Не было поиска по картинкам, не было голосового поиска, была одна функция, которая работала крайне хорошо. Все остальное было добавлено позднее в процессе роста компании.

Вы считаете себя умнее менеджеров из Google? Думаете, что вы наделите свой продукт десятком функций и от этого он станет привлекательнее? Будет тот же эффект, что и с историей про девочку (а была ли девочка? ;-)). Не забывайте, что использовать программу будут люди, а им не так уж легко освоить что-то сложное, продукт, который просто распирает от фитч.

Мой совет - один продукт, одна хирургическая группа, одна центральная фитча и команда хороших продажников. Чем раньше вы продадите свой продукт заказчику, тем раньше у вас появится информация, что же на самом деле хотели люди от вас. Почти все сегодняшние разработки - это интернет-сервисы. Добавлять в них новый функционал намного проще, чем в десктопные решения. Напишите сервис, найдите клиентов, а потом с ростом требований клиентов улучшайте его - так развивался facebook, так развивался amazon (иногда мне кажется, что менеджеров проектов нельзя подпускать к разработкам, если они не сдали своеобразный экзамен по истории успешных стартапов).

То же самое касается преждевременной оптимизации. Не нужно прикручивать к проекту то, что понадобится когда-то в будущем. Когда понадобится - тогда и сделаете. Не нужно резервировать в API сервиса команды - придет время, сделаете рефакторинг и добавите их. К тому времени структура API может десяток раз изменится, и то что вы когда-то заложили на будущее так и не дойдет до продакшина, зато изрядно намозолит глаза разработчикам.

Так что, уважаемые менеджеры проектов, не забывайте, что процесс разработки сродни процессу воспитания и обучения ребенка. Не будьте садистами, не пытайтесь научить всему и сразу, а то ведь гости разбегутся...