Comments 8
Как сказал Балу, это не песня, это пропаганда.
Даже пароль вспомнил, чтобы прокоментировать. По порядку:
1. "можно поставить цель: «Увеличить количество заполненных анкет на сайте в два раза» " - вроде очевидно, что ставить ее нужно не команде разработчиков, а как минимум Product Owner'у? Или вы из тех, кто нанимает бригаду строителей и говорит "постройте мне классное офисное здание, чтобы хотелось арендовать в нем офис. И сами придумайте план и т.д., в общем сделайте всю работу архитектора и маркетологов". Причем таких команд разработчиков - единицы, и стоят они столько, что вам точно не хватит денег.
2. "Если нет целей" - а зачем вы вообще начинаете проект без целей?
3. " Ответственность за успех разделяется" - как конкретно она разделяется? Разработчики получат долю прибыли? Премии? Или вы из тех, кто думает, что "программировать - это легко, и они не должны за это получать такие бабки, поэтому нагрузим их еще остальным"?
4. "Клиент, ожидая помощи от команды, не сформулировал цели" - если клиент настолько беспомощный, что не в состоянии В СВОЕМ ПРОЕКТЕ, который он по определению должен понимать лучше всех, определить очевидные приоритеты, то нехер на команду разработки перекладывать ответственность.
5. "Правильная цель должна быть конкретна, измерима, достижима, релевантна и привязана ко времени " - а еще остался бизнес, который не способен, пусть и с подсказками ПМа, это сформулировать?
Резюме: статья выглядит как очередная попытка не умеющего в управление переложить свою работу на исполнителей без дополнительной оплаты. И каждый раз эта идея терпит крах, потому что люди в разработку идут не для того, чтобы заниматься задачами управления и маркетинга, а потому что им нравится программировать/тестировать/дизайнить согласно поставленным задачам за нормальные деньги. А клиенту, если он не может сам разобраться со своими целями и т.д., нужно нанять Product Owner'а, маркетологов и т.д., а не пытаться заставить тюленя пахать поле.
Возможно я не совсем правильно спозиционировал статью. Я не утверждаю, что цели должны ставить обычные исполнители. Цели ставит команда, а в команде, по крайней мере у нас, всегда есть менеджерские роли ответственные за это. И да, клиент играет в постановке целей главную роль. Мы, как команда, просто помогаем ему с формулированием этих целей и определением задач, которые помогут этих целей достичь. Цели транслируются исполнителям в виде задач и приоритетов. Но это не значит, что исполнители просто бездумно работают по ТЗ, они в любом случае погружены в цели продукта и двигаются к ним.
Я так же считаю, что рынок сломан подходом «Без ТЗ результат ХЗ». Мне больно видеть ситуации, когда крутые продукты проваливаются просто потому, что обе стороны не договорились на берегу зачем мы что-то делаем и как. И потом возникают конфликты — клиент дурак, потому что не поставил нормально задачу, а разработчики плохие, потому что сделали не то, что я хотел. И все как будто бы согласны, что это нормально. Я так не считаю.
Поэтому, вместо того, чтобы ждать пока клиент наймет себе продакт оунера или научится сам формулировать задачи для разработчиков, я предлагаю проактивную позицию. Да, такой подход требует чуть больше погружения от исполнителей. Не все исполнители готовы переходить на такой уровень и это нормально. Они просто могут хорошо программировать/тестировать/дизайнить и оставаться востребованными.
Ну и по моему опыту клиент готов платить больше денег за такой подход. И это хорошие новости :)
Автору респект, что помогает заказчику понять, что у него за цели, но соглашусь с предыдущим оратором, что клиент без целей, это зло. Помогать ему понять, что он хочет можно, но по опыту - не благодарная работа. Ее начинает делать тот, кто ещё не наигрался в "бизнесмена", хотя сам всё ещё просто разработчик и периодически пишет код. Удовлетворить свое эго с таким заказчиком самое милое дело, но как любой порок до добра не доводит.
Много раз приходилось вытягивать и завершать такие мертворождённые проекты, какие-то хоронить. Их результат всегда в минус, как в деньгах, времени и что самое страшное ведут к выгоранию всех его участников.
Что же надо делать, так это создавать условия, чтобы цели формулировались и к вам не приходили без них в принципе. Делать это будучи внешним подрядчиком практически невозможно, но находясь внутри нужно:
Найти процессы у заказчика,
Оцифровать их,
Задавать вопросы до тех пор, пока он сам не увидит цель, сам не сформулирует варианты решения проблемы и не выберет наименьшее из зол.
Цели в начале разработки: как избежать провала проекта