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

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

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

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

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

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

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

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

Как страх перечеркнул идеализм

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

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

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

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

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

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

  • меня сочтут слабой или неэффективной и не выберут в следующий стоящий проект;
  • я потрачу всю прибыль от проекта и подведу компанию на которую работаю;

  • получу минус в карму от руководителя проекта;

  • я разочарую конечного клиента, и компания потеряет контракт.

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

Как становятся интровертом

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

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

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

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

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

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

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

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

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

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

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

Почему так сложно сделать оценку?

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

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

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

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

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

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

Для чего вам это знать?

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

0
48 комментариев
Написать комментарий...
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Kirill Solo

Я не айтишник, а дизайнер. На удалёнке почти 10 лет уже и выработал для себя четкое правило: я объясняю клиенту почему не надо делать так как он хочет, с фактами и доводами, если после этого клиент все-равно настаивает на своем видении, то просто делаю с сохранением скриншотов переписки. А когда начинаются правки, так как получается херня, то беру дополнительные деньги, так как я предупреждал)

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Kirill Solo

Ну вот про "потом исправим" я тоже предупреждаю, что это потом за отдельные деньги

Ответить
Развернуть ветку
badResistor

да да да!

Ответить
Развернуть ветку
Serge Sokolov

То есть мы умеем делать только унылое г@вно, напишите нам это или мы сами напишем. 

Ответить
Развернуть ветку
Кирилл Царенко

У нас в школе на уроке трудов нас учили, что пунктир - место сгиба, а прямая - линия, по которой нужно обрезать. Ты делаешь чертеж, далее отдаешь мастеру. Мастер сгибает пунктир и отрезает по прямой линии.
Программист так же как и мастер не должен задумываться о том, где в вашем изделии задумано загнуть, а где отрезать.
Если на выходе получилось не то, что вам нужно - вина ваша, а часы программиста все равно должны быть оплачены.

Ответить
Развернуть ветку
badResistor

На деле все несколько сложнее.

Ответить
Развернуть ветку
Кирилл Царенко

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

Ответить
Развернуть ветку
badResistor

Тут сложность в компетенции менеджеров часто получается.

Ответить
Развернуть ветку
Кирилл Царенко

Да, об этом я и написал в первом сообщении на примере с уроком труда в школе.

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

Потому, что заебались сражаться с ветряными мельницами

Ответить
Развернуть ветку
badResistor

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

Ответить
Развернуть ветку
Sakari Sauso

По таким моментам сразу нужно письма писать с описанием проблемы, чтобы в случае чего на тебя это не повесили

Ответить
Развернуть ветку
badResistor

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

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Aloha Nik

Переслал нашим менеджерам :)
Общение у нас всегда хорошее, но споры как делать иногда горячие. А бывает, что они хотят и виду какая сейчас ситуация с проектом, принимаю волевое решение сделать все правильно и с нуля. Бывает такой подход тратит лишние пару дней и внеурочное время, но потом самому легче поддерживать и совершенствовать. А менеджеры всегда давят на скорость, в итоге если следовать ТЗ, то получается "костыли и палки". Мой подход возможен только на одном проекте, если работать на конвейере, то все будет как в статье.

Ответить
Развернуть ветку
Олег Нечаев

Есть такой постулат, который помогает сразу отсечь сомнения и вопросы на начальном этапе - "делаем правильно и хорошо". Не пытаемся сэкономить время, деньги, сделать костыли, изгибнуться. Тупо - делаем правильно и хорошо. Нет любого из ресурсов в 2х кратном размере: денег, времени, скиллов - лучше за дело не браться, будет лотерея, а не результат.

Ответить
Развернуть ветку
Евгений Ковалёв

Да как ему следовать то на конвейере, это самоубийство

Ответить
Развернуть ветку
Олег Нечаев

Да не заводить себя в такую ситуацию. Не бояться остаться без денег, важного клиента или ещё чего. А конвейер свой запускать, а не строить его под каждого заказчика заново. Кто диктует условия - тот хозяин положения. Вот наши условия, не согласны - выход, где зелёный человечек. К таким прислушиваются, таких уважают и таким платят не вынося мозг. А если "вы скажите как хотите, мы изгибнемся", то работа - сплошная нервотрёпка, напряжение в коллективе, давление, стресс, отложенный пятничный алкоголизм, сексуальная дисфункция и инфаркт в 40, а пожить так и не успел. Когда клиент приходит к вам, у вас нимб должен светиться над головой "Я ЗДЕСЬ ГЛАВНЫЙ". Тогда и работа в радость и бабки в карман и клиент доволен результатами, если вы профи. Коллектив перестает давить снизу "зачем мы взяли так много за совсем мало денег", заказчик не качает права, а приходит как в ГИБДД за возвратом прав, расшаркиваясь и норовя заглянуть вам в глаза. 

Ответить
Развернуть ветку
Sergey Surikov

Вы не ИБМ, заказчик просто к вам не пойдёт с таким подходом.
Он отдаст свои деньги тем, кто больше наобещает.
Нужна золотая середина.

Ответить
Развернуть ветку
Yuriy Balaka

Работай только по своему процессу. Все так, спасибо Олег!

Ответить
Развернуть ветку
Anton Z.

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

Ответить
Развернуть ветку
Andrey Greenberg

Очень трезвое мнение и подход. Абсолютно согласен с автором. Хорошее ТЗ, как и проект строительства чего-либо, случаи единичные. В основном развит подход - вы там по месту сами определяйтесь как, где, что и куда поставить, вам виднее - вы же специалисты). Подразумевая видимо, что экстрасенсы

Ответить
Развернуть ветку
Maxim Syabro
 это большая и неоплачиваемая работа

следующий уровень осознания будет когда поймете что это должно оплачиваться

Ответить
Развернуть ветку
Георгий Хромченко

В управлении проектами есть отдельная тема - управление рисками. Просто оценивать работы - никогда не попадает, потому что всегда что-то может пойти не по идеальному сценарию.

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

То что менеджеры так не работают - это просто потому что в России практически нет менеджмента, все "начальники".

Ответить
Развернуть ветку
Кирилл Царенко

Алло! Алло! Сделайте мне аналог Авито, только лучше!

Ответить
Развернуть ветку
Sergei Timofeyev

Тыщи полторы рублей дам за это! :)

Ответить
Развернуть ветку
SL Potapenko

написать грамотное тз - задача аналитика, а не заказчика.
если вы, как разработчик, выполняете функции аналитика - закладывайте эти часы в тз, как этап "согласование и корректирование тз".
насколько понимаю, у многих фрилансеров это время иногда неявно заложено в рейт: сначала "бесплатно" анализируем условия задачи, потом заключаем договор и работаем за 100 $ в час
оценить сложность не стокового проекта до его запуска практически никогда невозможно. поэтому проект в тз разбивают на этапы, делают прототипирование, которое демонстрирует не только реализуемость тз, но и трудозатраты, и конечную стоимость.

Ответить
Развернуть ветку
Sergei Timofeyev

Причём написать ТЗ это не самая простая задача. По ГОСТ 34.602-89

Ответить
Развернуть ветку
Diego Salvador

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

Ответить
Развернуть ветку
Георгий Хромченко

Потому что хорошее ТЗ должен делать аналитик, и это - отдельная работа

Ответить
Развернуть ветку
Жрец Цукиеми

А если заказчик не принимает, "знает лучше/уже стопитсот лет отработал на заводе/он так привык/так всегда было, есть и будет"?

Ответить
Развернуть ветку
Георгий Хромченко

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

Ответить
Развернуть ветку
Ilya Rovda

Разделяй и властвуй. У каждого своя зона ответственности, по этому конечный исполнитель (в Вашем случае) рискует, пытаясь вносить правки в тз. Ведь это не его задача и на это, вероятно, не закладывается время.

Ответить
Развернуть ветку
Илья Ефимов

Вот поэтому весь рынок маркетинга в России и идёт по пизде уже третий десяток лет.

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

А вторые не могут себе позволить упустить клиента или показать свою слабость и потерять работу.

В подавляющем большинстве случаев всё это всё равно ведёт к проблемам, конфликтам, работе в ноль, потере клиента или обрыве цепочки услуг, так что лучше всего всегда говорить честно что к чему. В перспективе это даже будет выгоднее, потому что люди оценят. 

Ответить
Развернуть ветку
Serge Sokolov

Человек сидит на стуле. И хорошо сидит. Над ним вывеска. Компания сделает для вас любую разработку любого инновационого решения, превосходящего во всем все любые зарубежные аналоги. Не имеющего аналогов так же разрабатываем.  Выходим на международные рынки. Имеем в нашем портфеле заказчиков целую простыню непонятных логотипов.
 Ну как такому человеку! Под такое дело! Государству и не пойти на встречу! Откуда и деньги.  Тем более он сам государственный человек в прошлом. Ишь как на стуле то сидит. И нафиг ему ваши все. У него уже и так все есть.  

Ответить
Развернуть ветку
Игорь Кравченко

добро пожаловать в клуб)

Ответить
Развернуть ветку
Andrey Harchenko

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

Ответить
Развернуть ветку
Maria Ilyina
Автор

В основе любого ТЗ лежит список "хотелок", кто-то должен их определить.
Вопрос в том, кто и как потом должен доработать ТЗ. Полностью согласна с тем, что это должен быть технический эксперт, причем именно исполнитель, а не только аналитик. Об этом я и писала выше, не так много технических экспертов готовы ввязываться в разбор ТЗ по теперь понятным мне причинам. 

А говоря со стороны исполнителя, когда я и есть технический эксперт в своей задаче, идеально если заказчик выделяет этап и время на корректировку вводных. Но это тоже не залог успеха, так как выделить время - не значит принять результат штурма команды :( и, к сожалению, Agile, Scrum - тут не спасут. 

Ответить
Развернуть ветку
Олег Нечаев

Если заказчик выдвигает нелепые хотелки, то лучше с ним не работать. Максимум, когда стоит определиться - это когда вместе (да, это всегда коллективная работа) формируете понятное для всех (заказчика и исполнителя) ТЗ, результат выполнения которого приведет к результату или не приведет. Даже если вы сделаете то, на чем он вопреки здравому смыслу настаивает, после провала сначала он заминусит карму вам, и редко когда себе. 

Ответить
Развернуть ветку
Andrey Harchenko

ТЗ формирует лид(ы) программист / UX и т.д. проекта исходя из потребностей (хотелок), которые обозначил PO / заказчик.  Если лида(ов), как таковых нет на проекте, то непосредственно команда, в процессе обсуждения, которая будет заниматься реализацией технической части.
Если вы эксперт в технической части, то формируете ТЗ самостоятельно - берете на себя ответственность, что ваше ТЗ будет понятно команде, реализуемо в обозначенные сроки на существующей технологии с требуемым функционалом и не создаст архитектурных проблем в будущем. 
Если требования к проекту не определены до конца, то через MVP1, MVP2, MVPN до тех пор, пока у PO / заказчика не сложится понимание, что он хочет получить на выходе.

Ответить
Развернуть ветку
Sergei Timofeyev

Вы про то, что положено по ГОСТ или имеете ввиду что-то своё?

Ответить
Развернуть ветку
Кирилл Царенко

ТЗ не нужно "дорабатывать". Достаточно в процессе его составления, если у менеджера есть вопросы и абстрактные хотелки, проговорить подробно с программистом нюансы исполнения задачи. Менеджер не знает нюансом программирования, как и программист не знает истинные задачи на основе хотелок.
Ключ прост: обсуждение задачи друг с другом в процессе составления тех.задания. В таком случае оба получат то, о чем договорились, и проблем не будет.
Если специалист не хочет обсуждать тз перед его выполнением, значит с ним не нужно работать, потому что даже идеальное божественное техническое задание будет истолковано рандомным образом.

Ответить
Развернуть ветку
Serge Sokolov

Когда Жилет бегал со своей идеей по всему MIT ему везде так же говорили - Мистер, вы кто коммивояжер? Так вот такую бритву сделать просто невозможно. Почему? Ну дорого, непонятно для чего. Ну что Вам объяснять!  Ну сталь. Раскатать там до такой. Ну вы извините.  Но Жилет был упорным, и просто нашел нормального специалиста, который просто сел и все сделал. 

Ответить
Развернуть ветку
Кирилл Царенко

Алло! Алло! Сделайте мне аналог Wildberries, только все будет лучше!

Ответить
Развернуть ветку
Степа Моненко

Вот вот, еще косо смотрят, когда говоришь как делать не надо. По стилю написания уже становится понятно, что им все что ты говоришь, нафиг не нужно, и они думают как бы тебе это помягче сообщить. У меня все тоже самое. Предлагают тупое ТЗ, и на каждое предложение отвечают: "нет, пусть будет как в тз". Но это никак не касается тех, кто делает рабочие зеркала букмекера MaxLine https://stavki-zerkala.ru/maxline/ для обхода блокировок сайта.

Ответить
Развернуть ветку
45 комментариев
Раскрывать всегда