В мире накоплено немало знаний о том, как вести проекты. Разработаны ГОСТы, стандарты, методологии и целые идеологии, которые говорят нам, что нужно сделать, чтобы прийти от идеи к результату. Нам остается только выбрать рекомендуемый путь и следовать ему.

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

Этот инструмент в широких кругах называется ТЗ – техническое задание. Еще он может называться спецификацией, user story, заданием или требованиями к разработке, суть одна – этот документ помогает нам прийти из точки A в точку B. Именно с такой позиции мы будем его рассматривать, независимо от формализации.

Но довольно банальностей! Перейдем к мясу.

Конфликтология ТЗ. Завязка

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

А как же получается, что среднестатистический подрядчик-разработчик ИС, выполняя работы для клиента, может спокойно прерваться, заявив «в ТЗ такого не было»?

В этом есть суть распространенного конфликта сторон. Он возникает при построении информационных систем, в широком смысле, а также в разработке приложений, сайтов, CRM, настольного ПО и прочих лендингов (ирония) в более чем половине случаев.

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

Оговорка:

Единственное, где в таком случае допустимы отсылки к ТЗ – это продукты, где требуется высокоточная разработка с заранее известными или рассчитанными характеристиками.

Сюда я включаю наукоемкое программное обеспечение для производств, оборонки, космонавтики и т.п. Здесь действительно трудно представить ситуацию, когда претензии заказчика, при точном исполнении по ТЗ, были бы обоснованы. Основными заказчиками такого ПО являются обычно (но не исключительно!) государство или связанные с ним компании.

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

Что-то похожее испытывает штурман, когда ведет корабль к цели. Он еще не знает, куда придет. У него есть карта. А еще знания по навигации, небо над головой (а там звезды), радар, эхолот, интуиция и связь с берегом. А у врача, кроме плана, – 8 лет учебы и диагностическое оборудование, консилиумы, симпозиумы. Это их опорные точки и навигаторы в условиях неизвестности.

Впрочем, обо всем по порядку.

Убеждения, лежащие в основе конфликта

В основе любого поведения, действия или бездействия лежат убеждения. Иногда они находятся на поверхности, а иногда достаточно ловко скрываются от хозяина в лабиринтах его сознания. Копни чуть глубже – и вот оно – всплыло и никак не хочет тонуть. Не буду далеко ходить. Все они есть в этой статье. Беру их прямо из комментариев и перевожу на язык смыслов.

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

А шутка ли? – Нет! Скорее убежденность, выраженная шуткой.

Скрытая агрессия как защитный механизм. К сожалению, этот паттерн поведения зачастую переносится и на заказчиков. Клиент по умолчанию причисляется к касте дураков. Такое часто можно наблюдать на дорогах: «А, красный ярис? – ну, точно курица поехала». Говорить о том, что такое восприятие контрпродуктивно для дела считаю излишним.

Компания виновата и ее размер. Да, по факту, может быть это и так. Но почему же врач стремится вылечить пациента независимо от масштабов клиники и наличия бюрократии в ней, а программист даже не пытается, что-то изменить? Клятва Гиппократа определяет?

Плохой KPI всему виной. Не буду даже пытаться уточнять ТЗ – не оплатят. Не хочу тратить время.

Снова заказчик не знает, чего хочет. У меня проблем нет. Дистанцируюсь от этого и отсижусь. Не хочу переделывать.

Ответственность не моя, а заказчика. Подписал ерунду – сам дурак.

Никто и никому ничего не должен, но заплатить в 100 раз больше надо :)

Снова никто и никому ничего не должен.

Сами мы не местные, за продукт отвечать не хотим, инициативы нет. Уход от ответственности. Объяснение потребностью бизнеса.

Теперь сгруппируем все эти убеждения и обнажим наголо:

  1. Заказчик не знает, чего хочет / не в состоянии выразить свои желания.

  2. Задачи бизнеса решает компания/менеджмент (не я лично).

  3. Это не оплачивается (не учтено в KPI), значит, и делать не буду.

  4. Не хочу переделывать без внятного техзадания.

  5. Ответственность за ТЗ на заказчике (на бизнесе), т.к. он его подписал.

  6. Никто и никому ничего не должен.

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

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


Заказчик не знает, чего хочет / не в состоянии выразить свои желания

Что сделать с точки зрения психологии? Допустить, что заказчик несовершенен. Что ему может быть трудно, в силу разных причин, сформировать образ конечного результата. Допустить, что он вовсе не обязан разбираться в технических тонкостях проекта. Принять тот факт, что его язык описания задачи может отличаться от вашего.

А еще представьте, что вы у врача. Вам было бы приятно быть выслушанными? Или будет достаточно безразлично-сурового «ну, что там у вас» и взгляд, такой, исподлобья? Возможно, вам трудно найти у себя в теле источник боли, вы мучаетесь, боль неоднородна и непонятна. Вы бы хотели, чтобы доктор помог вам определиться с локализацией и причиной? Или, удостоившись дежурной пальпации и снисходительного простукивания, удовольствуетесь этим и ношпой, выписанной вслед? И добивание: «приходите через две недели, если сильнее заболит».

Что сделать физически? Помочь клиенту осознать свою проблему. Задать компетентные вопросы, проясняющие детали желаемого результата. Собрать необходимую информацию. Предложить разные варианты решений. Обозначить границы таких решений. Выработать удобные для сторон правила взаимодействия, отвечающие на вопрос «как мы будем общаться?». Определить подходящую методологию для ведения проекта.

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

Дополнительные пояснения. Ну, допустим, заказчик не знает, чего хочет. И что?

Помогите ему узнать это! Сделайте это частью вашей работы, если вы почему-то до сих пор считаете, что это не в ваших силах. Заказчик приходит к подрядчику с проблемой, с болью. И для начала хочет быть выслушанным. Развесьте уши – слушайте внимательно, не перебивайте, делайте вид, что вам интересно. А вам неинтересно? Тогда какого черта вы делаете на этой должности? Кто допустил вас до общения с заказчиком?

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

«Доцент тупой, но аппаратура при нем, при-нем!» А еще ваши деньги – они тоже при нем.  Он их платит бизнесу: вам лично или той компании, которую вы представляете. Если вам выпало обслуживать этого непонимающего человека, составлять для него бестолкового ТЗ, то сделайте это, хотя бы один раз, по первому разряду!

Просто попробуйте. И вы увидите, что дураки вовсе не являются таковыми при вашем активном участии. Волшебным образом они превращаются сначала в непонимающего клиента, потом в активно сотрудничающего, затем они раскрываются, располагаются к вам доверием как к профессионалу высокого класса, несут вам свои деньги и дорожат полученным опытом!

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

Задачи бизнеса решает компания/менеджмент (не я лично)

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

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

Это как в футболе болеть за своих: выиграли – мы, а проиграли – они. Инфантильно, слабовольно, жидко.

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

Если ТЗ делали лично вы – все то же самое. Только идете к клиенту, уточняете задачу и вносите корректировки в проект. Страшно? Больно? А кто сказал, что это легко? Выявить ошибку на ранних этапах работы обычно гораздо дешевле, чем сделать это в дальнейшем. Гораздо страшнее заложить из-за этого неправильную архитектуру в проект и узнать об этом на этапе приемо-сдаточных испытаний.

По моим наблюдениям все упирается в банальные страхи типа «клиент не заплатит», «уволят за ошибку» или «я буду выглядеть дураком». Признаюсь, что за свой 17-летний опыт проектной работы ни разу не видел таких последствий. Обычно, смелость в принятии сложных решений ценится окружающими и, если вы сумели вырулить ситуацию, то это только добавит вам профессиональных очков. А вот, если скрыли свою ошибку и об этом стало известно менеджменту и/или заказчику – вот тут уж палок не оберешься! О том, как нивелировать последствия таких ошибок, пожалуй, стоит написать отдельную статью.

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

В качестве примера: если задача из тестирования возвращалась на доработку более N раз, то использовать понижающий коэффициент от бонусной части за проект для программиста. Одновременно с этим заложить в процессы компании прозрачные механизмы эскалации проблем в случае обнаружения дефектов в ТЗ. Хорошей практикой будет «задай 7 вопросов». В рамках этой практики ТЗ не просто спускается программисту, но и обязывает его задать не менее 7 вопросов по данному ТЗ постановщику. Больше можно, меньше нельзя. Отслеживать работу этого механизма.

Ввести практику, при которой одновременно с ТЗ пишутся кейсы для тестировщиков. После чего ТЗ вместе с кейсами передается программистам. Проводить с персоналом коммуникативные тренинги, поощрять обмен информацией и сплоченность проектной команды.

Дополнительные пояснения. Подход «моя хата с краю» действительно встречается. В тех компаниях, где много бюрократии и формальностей между отделами эта проблема стоит особенно остро. Общая рекомендация такая: объединять отделы, формировать проектные команды, выстраивать управление ИТ-проектами не по вертикали, а по смешанному типу. Это когда специалисты из разных отделов физически работают вместе. Их объединяет одно пространство – они могут общаться друг с другом в любой момент, когда того требует ситуация.

Нещадно сносить всю бюрократию: согласования, подписания, служебные записки и т.д. Проблемы решаются здесь и сейчас – ключевые лица всегда доступны. Процессы решения проблем прописаны и известны участникам проекта.

Это не оплачивается (не учтено в KPI), значит, и делать не буду

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

Что сделать физически? Продолжать так же качественно делать свою работу (как и сейчас), но уже с осознанием того, что я описал с точки зрения психологии. Если вы напрямую работаете с заказчиком, например, вы – фрилансер, то доходчиво объяснить клиенту, за что он вам платит и как следует описать процесс изменения требований в единой связи с их оплатой, убедиться, что вас поняли.

Кстати, если вы до сих пор не знаете, за что вам платит клиент, спросите прямо у него – узнаете много интересного. Когда узнаете, сделайте это своей сильной стороной. Если вы наемный специалист, делайте все то же самое: качественно работайте, подойдите к руководству и узнайте, за что оно платит вам. Предложите ваше видение о том, как можно решать задачи клиентов эффективнее, как не допускать ошибок при постановке задач и что вы можете сделать со своей стороны, если увидите их на своем участке работы.

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

Что сделать управленчески? Таки внедрить процессы критической обработки ТЗ программистами с возвратом на уровень постановщиков, в случае обнаружения косяков. Обеспечить прозрачность и выполнимость таких процессов. Изменить KPI по рекомендациям «Задачи бизнеса решает компания/менеджмент (не я лично)». Отправить всех методистов, постановщиков и аналитиков на тренинги по написаниям ТЗ. Выявить и уволить людей, допускающих выполнение заведомо некорректных требований в ТЗ без их предварительной верификации.

Дополнительные пояснения. Часто за формулировками «это не оплачивается» стоит банальная лень и страх изменений. Обычно у таких специалистов, все в действительности хорошо – оклад их устраивает, а больше денег им и не нужно. Перестраиваться они не хотят, а потому избегают любых попыток привлечь себя к анализу требований.

Такие сотрудники 100% формалисты и бюрократы. На вопрос «чей косяк?» они всегда сошлются на «убогое ТЗ», «криворуких постановщиков» и трудовой договор. Они редко признают свои ошибки, т.к. считают, что их допустил кто угодно, но не они. Если перед ними встает выбор сообщить об ошибке или допустить ее – сделают так как написано в ТЗ, т.е. с ошибкой, даже если спокойно могли бы избежать этого. Являются очевидными саботажниками.

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

Не хочу переделывать без внятного техзадания

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

Чтобы понять всю абсурдность такой позиции достаточно представить как врач, после неудачных попыток вылечить вас, просит сделать для него (более) внятное ТЗ. А если, в автосервисе от вас вдруг попросят такое ТЗ, как вам? Понравится?

Ваши опасения вполне понятны. Но они бы не вылились в переделки, если бы изначально вы провели более качественную диагностику проблемы и верификацию требований. Таким образом, если перед нами замаячило такое убеждение, то в 95% случаев мы допускаем ошибку раньше – скорее всего, спешим быстрее начать работу, не проявляем достаточной вовлеченности при выявлении проблемы, описании конечного результата. Допускаем промахи во взаимодействии с заказчиком (постановщиком), не погружаемся в детали.

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

Что сделать физически? Если вы – исполнитель ТЗ, то нужно активнее участвовать в сборе требований и их верификации и формализации. Об этом я уже писал выше.

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

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

Что сделать управленчески? Организовать совместную работу над ТЗ аналитиками и тестировщиками. Предполагается, что одновременно с написанием ТЗ ведется подготовка сценариев тестирования и все это передается заказчику на ознакомление. Смысл в том, что хороший сценарий тестирования обычно достаточно нагляден. Если его передать заказчику перед началом работ, то ему будет проще оценить, соответствуют ли его желания описаниям. А у разработчиков будет меньше вариантов ошибиться. В рамках управленческих подходов следует также зафиксировать процедуры совместной работы в административных регламентах компании. Рассмотреть переход на agile.

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

  1. Быть на голову выше своих конкурентов, работающих по схеме «Дайте ТЗ». Вместо этого стоит перейти на схему:

    проблема (ставит заказчик) – анализ (делаете вы) – предложения (вы) – решение (вы)

    + постоянное взаимодействие с получением обратной связи и корректировка действий.

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

Ответственность за ТЗ на заказчике (на бизнесе), т.к. он его подписал

Что сделать с точки зрения психологии? Уверен, что бизнесы, которые не поймут, что бюрократия – это зло, скоро умрут. Говоря о бизнесе, я конечно же, имею ввиду менеджмент и сотрудников, стоящих за ним. Оглянитесь вокруг: сегодня вы можете вернуть товар в магазин без чека, просто, если вам не понравится его вкус или качество! Вы можете заказать на дом одежду, померить и вернуть обратно, ничего не купив. Принести в ремонт ботинки или сумку, находящиеся на пожизненной гарантии, абсолютно бесплатно и без чека.

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

Варенье не понравилось – дали другое – классно! Буду покупать в этом магазине! Не смог попасть к врачу в этот раз, но приду в следующий, т.к. со мной были вежливы и обходительны именно здесь. Не подошел спортивный костюм – обменяю через пару недель (но тоже в этом магазине, ибо классно).

О чем это я и как это связано с ИТ? А это об уровне зрелости компании, о понимании тонких материй. Это не про то, как зачеркнуть ценник и продать куртку «со скидкой», а когда у нее сломается молния развести руками. Не про то, как поставив на весы лишний грузик, обвесить на картошке и заработать рубль здесь и сейчас «на дурака». Это про игру в долгую.

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

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

В этом качественно иной подход к современному ИТ-бизнесу. Осознав это, вы сможете зарабатывать несравненно больше. Разбюрократизируйтесь в своей голове! Сейчас это делают даже государственные поликлиники и почта России :)

Что сделать физически? Спросить у клиента, что его действительно не устраивает и доделать работу. В моем опыте часто бывает такое, что клиенту не хватает какой-то мелочи, но при этом программист или компания встает в позу и «принципиально» не дорабатывает на 99% выполненную программу.

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

Возьмите себе дополнительные очки за счет вашей гибкости и умения следовать к результату, а не потакать формальностям!

Что сделать управленчески? Перевести внутренние процессы согласований в электронную форму. Сместить фокус с бумажек на СО-трудничество, поставить во главу угла взаимодействие вместо формальностей. Научить аналитиков и прочих постановщиков визуализировать будущие результаты работы (прототипы, мокапы) – они, обычно, более внимательно изучаются заказчиками. Хороший прототип, особенно динамический, может покрыть в себе до 90% ТЗ. Остальное покрывается описанием процессов в каких-нибудь понятных нотациях (типа BPMN) и верхнеуровневыми (небольшими) ТЗ.

Дополнительные пояснения. А не будет дополнительных пояснений здесь) Мысль достаточно полная, чтобы начать меняться прямо сейчас.

Никто и никому ничего не должен

Что сделать с точки зрения психологии? Попытаться осознать это стихотворение. Хотя не надо пытаться. Вы ведь вовсе не должны.

Ну, когда же наконец я пойму: я не должен ничего никому, я не должен ничего никому, в том числе и себе самому.

Спи спокойно, мой Господи-Боже, обнимая вселенскую тьму, никому ничего ты не должен, в том числе и себе самому.

И когда ты молитву услышишь, медитацию, то или се, ты и волосом не поколышешь, потому что не должен, и все.

В.Л. Леви

Что сделать физически? Уволиться. С такими убеждениями начальник не должен платить вам зарплату, а вы не должны работать на него. Я уж совсем не говорю о ТЗ – это за гранью понимания.

Что сделать управленчески? Проводить более тщательный отбор кандидатов на работу.

В качестве заключения

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

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

В лидерах по распределившимся голосам следующие тезисы:

  • Перед сдачей работы не проверяю, все ли сделано по ТЗ – 103 голоса.

  • Читаю ТЗ по диагонали – 100 голосов.

Что это означает для нас с вами и рынка в целом? Считаю, что ничего хорошего. И то, и другое говорит о том, что заказчик не получит ожидаемый результат. Двойные потери: первый – на этапе чтения ТЗ по диагонали, второй – на момент сдачи работы, абсолютно точно приведут нас к доделкам/переделкам. При таком подходе говорить о хорошем климате на рынке ИТ-услуг, увы, не приходится.

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

Классных проектов вам :)

Комментарии (16)


  1. powerman
    19.04.2022 00:59
    +3

    Многие боятся самой идеи наличия ТЗ, потому что им кажется, что это путь назад, к водопаду и очень медленной разработке, а у нас тут надо очень быстро, по аджайлу, поэтому "на написание ТЗ времени нет". А по факту, если умеючи, то наличие ТЗ сильно экономит время разработки и никак не мешает практиковать аджайл. Ключевое слово "умеючи", разумеется.


    1. PereslavlFoto
      19.04.2022 01:47
      +1

      Время разработки = время на составление ТЗ + время на исполнение ТЗ + время на разработку готовой программы.

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


      1. powerman
        19.04.2022 03:28
        +6

        Ну вот да. То, что Вы говорите - довольно типичное представление, из-за которого на ТЗ "экономят", чем наносят проекту довольно значительный вред.

        Я на это смотрю иначе. В процессе разработки приложения всё-равно приходится продумывать все детали реализации, от высокоуровневой архитектуры до мелких низкоуровневых вопросов вроде областей ответственности отдельных модулей/классов/функций. При этом нередко оказывается, что о чём-то подумать забыли, но всплывает этот факт сильно позднее. А, как известно, вносить изменения на ранних этапах (вроде проектирования "на бумаге") значительно дешевле, чем на поздних (в коде, при интеграции или тестировании). Поэтому я считаю разумным разделить ту работу по проектированию, которую в любом случае приходится выполнять (будь то в голове во время набора кода, или при написании ТЗ ещё до набора кода), на два раздельных этапа: написание ТЗ и реализация по этому ТЗ. Этот подход позволяет выявить большинство проблем ещё до появления реального кода, и исправить их намного дешевле.

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

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

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


      1. balandinve
        19.04.2022 08:55
        +1

        На одном из мест работы был следующий подход, но оговорюсь, что ТЗ было на фичу, а не к проекту в целом.
        1. я работаю по ТЗ над фичей
        2. параллельно, аналитик и менеджер общаются с заказчиком по поводу новой фичи
        3. аналитик по итогу п.2 формирует ТЗ и иногдя задает мне технические вопросы по возмоной реализации
        4. я заканчиваю с п.1 и получаю ТЗ для новой фичи из п.3


        1. SpecPortal Автор
          19.04.2022 10:12

          Хороший подход в единой рабочей связке. И работа делается, и новые задачи в пул собираются, проходя технический фильтр (вашу консультацию)! Из видимых минусов, наверное, то, что трудно заложить правильную глобальную архитектуру для будущего масштабирования. А вы сами видите какие-то минусы в таком подходе?


          1. balandinve
            19.04.2022 13:17

            Минус, наверное в том, что заказчик все равно внесет коррективы, когда увидит mvp), но не всегда наблюдалось. Как раз у заказчика развязывались руки, когда хотелки были написаны на коленке.
            Про Ваш минус - да, имеет место быть, но можно нивелировать риски в п.3.
            Такой подход хорошо живет там, где налажены процессы. В противном случае все скатывается в "уже вчера")


  1. MrForser
    19.04.2022 08:50

    В поликлиниках и крупных автосервисах есть персонал который работает с клиентами, а есть люди, которые с клиентами не работают. Аналогично в разработке - есть аналитики, есть программисты, есть менеджмент. В некоторых компаниях какие-то роли объединены, и программист общается с заказчиком, выясняет его потребности и составляет ТЗ. В других компаниях программист может вообще не иметь доступа к заказчику, а работать только по задачам, спускаемым сверху - что бизнес с аналитиками придумает, то наш программист и будет делать. В аналогии с больницей он подобен сотруднику хим. лаборатории - ему приносят материал, он делает анализы, а ставить диагнозы и назначать лечение не его задачи. Разумеется это не снимает с него ответственности в случае, например, если на анализ А принесли материал Б - об этом надо сообщать ответственным лицам, а не писать отсебятину, в надежде что "и так сойдет", но и звонить персонально клиенту и договаривать с ним на забор материала - скорее всего оверкил (зависит от процессов).
    Мне кажется, в данной статье автор во многом пытается доказать кодерам, что им надо быть аналитиками. Ну и немного говорит про ответственность и работу на результат. Ответственность и работа на результат - это все верно, а вот для аналитики все же часто нанимают отдельных специалистов, потому что это отдельная сфера деятельности и чтобы стать хорошим аналитиком, нужно этому учится. Хотя бы того же Вигерса прочитать для начала. Для общего развития будет в любом случае полезно, но нужно ли это всем...


  1. karon
    19.04.2022 10:14

    Даже приятно увидеть себя на скринах.
    А теперь давайте вспомним, что такое современная разработка.
    Программист очень часто не видит ни тз, ни чего либо еще кроме задач, нарезанных лидом и аналитиком. Его могут перебрасывать между проектами, у него нет контекста общения с заказчиком. Он безусловно должен озвучивать проблемы, но не имея контекста не всегда может делать это корректно. В данном случае очень похоже на желание заменить "дорогих" лидов и архитекторов, на "дешевых" разработчиков.

    Текст написан для лидов\аналитиков\небольшой части сеньеров, но никак не для большинства разработчиков.


    1. powerman
      19.04.2022 18:37

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


      1. Zenitchik
        19.04.2022 18:56
        +1

        Вы смешали всё в одну кучу. Я работаю над одним и тем же продуктом уже 10 лет. Ни о каких "продуктовых стартапах" никогда не слышал. При этом между мной и клиентом два слоя других людей. Зачем мне прямой доступ к клиенту? Разве что баг на месте "пощупать".


        1. powerman
          19.04.2022 19:25

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

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

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

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

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


      1. karon
        19.04.2022 19:24

        Это валидно, если это мини компания или фриланс. Где программист выполняет несколько ролей. В компании с выстроенными процессами, это разные люди. Никто не спорит, что в идеале, они все были взаимозаменяемые, и т.д
        Но вот например пара человек из моей команда:
        - Крутой спец, которого на пушечный выстрел нельзя подпускать к заказчику, или получим кучу бомбежа, "они все идиоты".
        - Крутой спец, который пошлет заказчика нахер.
        - Неплохой разраб с жутким синдромом самозванца, а следовательно с проблемами, когда надо отстоять свою точку зрения.
        Да со всеми тремя идет работа, и эти проблемы исправляются. Но они не хотят, и не смогут выполнять работу менеджера\аналитика\лида. И они прекрасно вписываются в свое место.


  1. atsi
    19.04.2022 10:44
    +1

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

    На нынешнем месте работы в более мелком предприятии ТЗ не делают, все на коленке, как левая нога решила - переделок огромное море, кривущие системы, вечно какие-то логические тупики и костыли по устранению оных. По сути меня одну здесь не устраивает отсутствие четкой зафиксированной постановки/документации/ответственности, а вот моих коллег (без какого-либо опыта работы с ТЗ) ничего не смущает, они не видят проблемы (а на самом деле все проще - я все сделал правильно, пользователь сам дурак, не знает чего хочет, не может мне объяснить правильными словами, я никому ничего не должен, мне за интуицию не платят и тд и тп из статьи выше).

    в общем - да, ТЗ это ресурсозатратно, но в плане организации конструктивной работы вполне обосновано. Можно рассмотреть как показатель зрелости специалиста (личности?).

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


    1. powerman
      19.04.2022 18:42

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


  1. as3k
    19.04.2022 16:37

    С того времени, как стал требовать ТЗ перед началом разработки сайтов - у меня нет клиентов на создание сайтов. И черт с ними, надоело переделывать самим за собой "чтобы посмотреть", потому что всегда получал ТЗ вида - "ты этим занимаешься, тебе лучше знать". А потом вдруг "лучше знать" начинает клиент, когда задача уже выполнена. Удобно, ТЗ то нету.

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

    Представляю, что творится в командах разработки, ну нафиг такую работу.


    1. powerman
      19.04.2022 18:49
      +1

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

      И, да, аппрув ТЗ от заказчика не значит, что у его требования не изменятся когда он увидит первый прототип. Изменятся. Это нормально. Просто изменившиеся требования надо внести в ТЗ и снова отдать на аппрув. (Брать за них дополнительные деньги или нет - это уже зависит от нескольких других факторов и в данном контексте не так важно, но если брать - то это обычно проще сделать, если заказчик участвует в процессе внесения изменений в ТЗ и понимает, из-за чего увеличилась стоимость проекта.)