Почему разработчики не спорят с бредовым ТЗ?

Интересно, есть ли на нашей планете человек, которому доставались только идеальные ТЗ? Уже десять лет я работаю маркетологом и знаю, о бреде в ТЗ не по наслышке. Ещё не поняли откуда? Я одна из тех людей, которые творят этот бред.

Ленивые, нерешительные, безыдейные, люди не понимающие бизнес цели и не желающие принести деньги в компанию — такими я видела команды разработки еще год назад.

Каждый день для меня был словно борьба с безынициативной проектной командой ради великой цели. Что изменилось? - Я стала одной из них.

Мне, как маркетологу, это понимание давалось особенно тяжело. Есть бизнес цели и за них в ТЗ отвечает заказчик, но есть куча нюансов, раскрывающихся на этапе технической реализации. Почему разработчику не указать на ошибку или недоговоренность в ТЗ, если он знает, что можно сделать лучше? Зачем делать то, что впоследствии не будет работать? Наверно, я бы бесконечно мучила себя этими вопросами, если бы мне не случилось поработать по другую сторону продакшена.

Декретный отпуск внес в мою занятость свои коррективы. Уже почти полгода, как я стала вынужденным аутсорсером: не заказчиком и даже не руководителем проекта, а головой и руками.

Теперь мое время перепродают клиентам от проекта к проекту, никакой рутины, жёсткие рамки проекта и только удаленное общение.

Как большинство разработчиков, работающих на проектах, теперь я отмечаю время, есть внутренний рейт, по которому мне оплачивают часы, и есть внешний, по которому мое время продают клиенту.

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

Итак, как изменилось мое сознание?

Исследования в поиске истины, кардинальное переосмысление задач и генерация неожиданных решений — все это ушло на второй план.

Неожиданно я стала бояться трекать дополнительные часы, а я не из числа робких.

В поисках «почему» я раскопала несколько причин своего страха:

Итого четыре огромных минуса против честолюбия и призрачного шанса, что конечный заказчик поймет гениальность твоей идеи на этапе проекта, а не через год после релиза/выпуска продукта или материала.

Я всегда была экстравертом до мозга костей и придерживалась утверждений «зачем писать ТЗ — все и так понятно» и «сейчас зайду объяснить».

Жизнь учит, поэтому вскоре я перешла на «подождите включу диктофон» и «я записала, что вчера обсудили, чтобы вы не говорили, что этого не было».

Конечно, прогресс на лицо, но в обоих случаях процесс без разговоров был немыслим.

Пришло время нового этапа, а точнее сразу трёх.

Разочарование. К сожалению, ТЗ, как правило, не совершенны и с этим нужно смириться. Вам повезло, если оно хотя бы есть.

Хуже, если его вовсе нет, но «по ходу пьесы» оказывается, что заказчик в своей голове уже все придумал и представил, но никогда тебе об этом не расскажет.

Еще хуже, если заказчик придумал и даже записал, но ты точно знаешь, что это не будет работать и никогда не принесет ему ни рубля.

Ну и совсем плохо, если ты об этом сказал, а он решил, что ты ничего не понимаешь или разводишь его на дополнительные траты.

Осознание. Чтобы сделать задачу быстро ее нужно принять, а не обсуждать. В противном случае ты рискуешь перейти к наихудшему варианту.

Принятие. Здесь включается чувство самосохранения. Я просто перестала присутствовать на встречах, где это возможно. Стать интровертом — это выход, чтобы ни сорваться, ни ухудшить ситуацию, ни потратить время проекта на разговоры и не вылить все, что накопилось.

Так как я хотела уже не будет, поэтому переходим на «вы там обсудите и пришлите мне списком».

До недавнего времени, я была уверена, что неумение делать оценку лишь говорит о недостатке опыта и нежелании работать на благо продаж. Мой опыт уже около 10 лет. Я всегда знала сколько времени трачу на аналитику, упаковку идеи продукта, текст или презентацию.

Вот только время было «резиновое».

В первый же день работы аутсорсером на проекте я вылетела из собственной оценки в два раза, так как ТЗ не включало в себя все ожидания клиента, а без них работу не принимали.

Мне было стыдно показать реальное время, поэтому я отметила часы согласно первой оценке. Сил ушло много и это было неприятно.

Первая оценка сделала меня осторожнее. Опыт опытом, но теперь я избегаю оценок. Заложу много — решат, что я некомпетентна, мало — отработаю себе в ущерб. Пусть лучше менеджер заложит (как же меня раздражало такое поведение у программистов).

Сейчас для меня оценка — больше не бросить пыль опыта в глаза, это большая и неоплачиваемая работа. Иногда я делаю около тридцати процентов задач от еще не утвержденного проекта, чтобы понять его трудоемкость.

Этот материал не претендует на достоверность и не может быть назван исследованием. Это лишь мой личный опыт. Я допускаю, что есть люди, которые имеют схожие чувства и задают себе те же вопросы. А когда я вернусь к своему обычному роду занятий, обещаю быть к команде внимательнее.