30 дней доступа к подписке бесплатно по промокоду
LETO
Активировать
18+
Личный опыт
Maria Ilyina
3200

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

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

В закладки
Слушать

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

{ "author_name": "Maria Ilyina", "author_type": "self", "tags": [], "comments": 47, "likes": 36, "favorites": 50, "is_advertisement": false, "subsite_label": "life", "id": 129257, "is_wide": false, "is_ugc": true, "date": "Sat, 23 May 2020 22:32:05 +0300", "is_special": false }
18+
Отпуск начинается с кино
30 дней подписки бесплатно по промокоду
LETO
Активировать
30 дней подписки КиноПоиск HD бесплатно для новых пользователей, которые ранее не оформляли подписки сервиса КиноПоиск HD, при условии привязки банковской карты. Подписка КиноПоиск HD 99 ₽/месяц. до 31.08.2020 г., далее — автопродление 269 ₽/месяц. Условия: ya.cc/4y4UX
Объявление на vc.ru
0
47 комментариев
Популярные
По порядку
Написать комментарий...
9

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

Потому что в 99.9% случаев, заказчик начинает сливаться по двум причинам:
1) Не хочет заморачиваться дальше. Ведь он свои 3 страницы ТЗ и так составлял полгода, а тут переделывать, да еще и грамотно расписать, еще и с учетом новых правок..ну его нафиг. 

2) Считает, что программист хочет состричь с него побольше денег, поэтому дополняет ТЗ всем лишним, ненужным и сложным, чтобы побольше содрать. 

Как итог, спорить с заказчиком относительно ТЗ смысла нет никакого. Поэтому я клиентам сразу говорю - у вас недочеты тут, там и вот там. Если делать как вы хотите, это может привести к таким-то проблемам. Либо платите мне n денег, и я напишу правильное ТЗ. В 90% случаев мне отвечают: "ничего страшного, делайте по тз, если что потом исправим". Вот поэтому и спорить смысла нет.

Ответить
3

Вот вот, еще косо смотрят, когда говоришь как делать не надо. По стилю написания уже становится понятно, что им все что ты говоришь, нафиг не нужно, и они думают как бы тебе это помягче сообщить. У меня все тоже самое. Предлагают тупое ТЗ, и на каждое предложение отвечают: "нет, пусть будет как в тз".

Ответить
3

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

Ответить
1

Я не айтишник, а дизайнер.

А тут без разницы. Я по совместительству еще столяр и строитель, и там и там такие же кривые "ТЗ". И там и там предупреждаешь. И там и там в 90% случаев говорят: "да ладно, все будет хорошо, потом исправим".

Насчет скринов да, аналогично. Поэтому никогда не позволяю диктовать ТЗ по телефону. А большинство как раз говорят: "ну я не знаю что писать, мне легче по телефону сказать".

Ответить
0

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

Ответить
1

да да да!

Ответить
0

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

Ответить
4

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

Ответить
1

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

Ответить
1

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

Ответить
0

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

Ответить
0

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

Ответить
5

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

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

Ответить
3

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

Ответить
3

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

Ответить
0

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

Ответить
2

Да да да, есть уроды, которые любят в начале сказать: "делайте как мы сказали", а в конце качать права: "почему вы так плохо сделали? Все работает не так как мы хотели". Поэтому главное предупредить, дождаться ответа, заскриншотить, и со спокойной совестью идти и делать гавно)

Ответить
3

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

Ответить
2

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

Ответить
0

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

Ответить
5

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

Ответить
1

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

Ответить
0

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

Ответить
2

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

Ответить
2

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

Ответить
2

 это большая и неоплачиваемая работа

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

Ответить
2

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

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

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

Ответить
2

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

Ответить
0

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

Ответить
1

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

Ответить
2

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

Ответить
1

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

Ответить
1

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

Ответить
0

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

Ответить
0

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

Ответить
1

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

Ответить
1

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

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

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

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

Ответить
0

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

Ответить
0

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

Ответить
–1

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

Ответить
1

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

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

Ответить
1

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

Ответить
0

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

Ответить
0

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

Ответить
0

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

Ответить
0

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

Ответить
0

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

Ответить

Комментарии