Про управление проектами написана тысяча книг. Разработано огромное количество методологий и проведены миллиарды тренингов.
Но при этом, почти каждый, кто управлял проектами или даже просто участвовал в них, знает – проекты опаздывают. Причем не важно – будет ли это производство программ, подготовка к Олимпиаде или строительство атомной станции. Проекты – опаздывают.
Некоторые методологии просто предлагают принять это за данность и как-то приноровиться (например, планировать только ближайший этап), другие пытаются навести армейскую строгость, проводя Deadline и вводя «реакцию на отклонения».
Я хочу поговорить о другом. Не о том, почему проекты опаздывают, и как этого избежать, а о том, зачем они опаздывают. Ведь если так подумать – ну не ужели можно все сбросить на ошибки планирования? Ведь, вроде взрослые, опытные люди, ну не могут же они все время ошибаться? А раз не могут – значит делают это намеренно, не так ли?
Приведу на ваш суд три возможных ситуации.
Ситуация первая. Швейцарский нож или «а еще кружок по фото, а еще нам петь охота»
В проект последовательно добавляются все новые и новые функции. Изначально задуманный простенький календарик превращается в систему планирования мироздания с элементами соцсети и игровым компонентом. Создание каждой новой функции требует времени и сил, но участники аргументируют: «так нужно, так как возрастает полезность продукта для потребителя».
В основе этой ситуации лежит несколько нелогичных базовых предпосылок:
1. Каждая новая функция добавляет полезности продукту.
Что совсем не обязательно. Например, меня страшно раздражает пилочка для ногтей в моем ноже. И я перестал пользоваться Nero когда он стал не только прожигать диски.
Более того, даже если сама по себе функция хороша, она утяжеляет продукт, делает его более сложным в восприятии и использовании. Причем усложнение нарастает как степенная функция, а вот польза прирастает арифметически.
Легче сделать отличный простой продукт, чем хороший сложный.
2. Продукт должен нравиться всем
А у людей разные запросы, и соответственно под каждый запрос мы должны предложить свое решение, свою функцию. Представление идет откуда-то из доисторических племен – где самец должен нравится всем самкам, чтобы оставить как можно больше потомства. В реальности большинству из нас и с парой десятков партнеров не справиться.
Так же и с проектами – не надо нравиться всем-всем. Гораздо легче понравится части, но сильно. Посмотрите на iPhone в нем нет огромного числа очевидных функций — а успех на лицо.
3. Мы одиноки в этом мире
Если мы не добавим функцию, в наш продукт, пользователи не смогут…
Ах, оставьте… Кроме нас есть еще тысячи способов, как сделать это. И зачастую это понятнее, проще и привычнее для пользователя, чем наши замечательные функции. Не стоит прикручивать собственную социальную сеть – для этого есть вконтакте и FB, не стоит писать свой собственный месенджер – пользователи отлично справятся уже существующими.
Ситуация вторая. Глянец или «мне нужно, чтобы блестел»
Проект уже полгода как готов. Красивый, точный, почти без багов. Его можно было бы выпустить прямо сейчас, вот только надо подправить немного вот здесь… И мы правим сначала дизайн, потом оптимизируем память, ловим баги, и снова правим дизайн. Оттачиваем каждое слово в инструкциях и системных сообщениях. Немного переделываем работу первого, второго и третьего. Выпуск проекта снова откладывается…
В основе этой ситуации опять лежат неверные предпосылки:
1. Наш продукт должен быть безупречным.
Говорят, что, создавая ковер, мастер специально делал один завиток узора несимметричным, для того, чтобы ковер не был идеальным. Такой завиток, в переводе на русский язык, назывался «мы живы». Безупречность – это признак умирающего продукта.
2. Каждая правка, делает продукт лучше.
Каждое изменение размывает первоначальный концепт. Через некоторое время дизайн начнет сыпаться, тексты станут казенными, а баги все равно появятся, но в неожиданных местах.
Если проект не получается «сделать хорошим» — полировка не поможет. Улучшения – как пряности при готовке. Они нужны, они помогут скрыть некоторые огрехи изначального рецепта и обогатят вкус. Но в какой-то момент надо остановиться – иначе еду будет невозможно есть.
Либо выпускайте «как есть» — или переделывайте продукт целиком, начиная с концепции.
Ситуация третья. Проверка боем или «невзлетевший самолет не разобьется».
Проект готов. Но мы все почему-то ждем.
Каждый выпуск продукта это проверка, экзамен. Для команды проекта, для инвестора, для заказчика. Выпустить продукт – значит потерять контроль над ним, значит получить оценку от внешней среды. Мы этого хотим. И очень боимся – ведь оценка может оказаться и плохой. А страх — он всегда иррационален.
А какие «зачем» замечали вы?
Автор: DenisVitman
