В последнее время у меня создается четкое ощущение, что людей пугает
аббревиатура ТЗ, что суть этого документа сильно обесценивается. Воспринимается как что-то бюрократическое и излишнее. Но дело в том, что какие бы мы “открытые к изменениям и гибкие” не были - психология нашей памяти, вовлеченности и когнитивных ошибок восприятия не меняется. Более того, из-за постоянного состояния “онлайн”, навыки фокусировки снижаются.
Если смысл всей статьи донести в одной фразе, то “ТЗ - это диалог, который нужно записать”.
Я бы разделила статью на три блока:
- почему в диалоге важны оба участника, и как роль каждого зависит от конкретной ситуации (5 вариантов)?
- что такое записать диалог? как выстроить работу в каналах коммуникаций, чтобы использовать это как ТЗ? Что делать если у вас нет структуры ТЗ?
- всегда ли ТЗ - это процесс?
Потом совсем чуть-чуть расскажу про данные. И завершу тем, почему ТЗ не стоит бояться с позиции конкретных участников, а не проекта в целом.
В диалоге важны оба участника. Ключевая мысль в том, что ответственность лежит на плечах не только того кому требуется выполнение заказа - но и на плечах исполнителя. В большинстве случаев диалог ведут люди, которые имеют разные компетенции( исключение субподряд). Роль исполнителя в том, что именно он знает какие правильные вопросы, раскрывающие профессиональные аспекты задачи необходимо проговорить, они могут быть абсолютно недоступны клиенту ( в том числе в силу отсутствия не только технических навыков, но и опыта). Не нужно злиться на клиента - “а что сразу то не сказал” - подумайте о том “ а что сразу не спросили”. Важное значение имеет и сама форма диалога( про это чуть ниже ). Формат так же лучше задать исполнителю, ведь делать (“обрабатывать вводные”) ему.
В свою очередь, конечно, все таки заказчик озвучивает свои нужды и намерения, но и заказчики бывают абсолютно в разных ситуациях - от этого будет зависеть как выстраивать диалог и какие могут возникнуть риски.
Советую изначально понять с кем вы имеете дело. Личная встреча обычно многое ставит на свои места - если вы общаетесь через посредника “на котором все держится” , “напроситесь” хотя бы тихо послушать.
Попробую рассказать с позиции исполнителя про варианты развития событий.
Заказчики знают что хотят, и как это сделать.
Скорее всего у них будет уже довольно полное тз ( и даже понимание стоимости проекта ;) ) - в виде какого-то другого артефакта и вашей задачей будет его подробно изучить - задать вопросы и если в каких то моментах у вас принято делать иначе - подсветить это и зафиксировать в тз. Бывает, что вам дают переформатированное комерческое предложение от другой компании - и, на самом деле, в нем есть аспекты абсолютно непринципиальные для заказчика, но впоследствие дорогие для вас.
Смело берите на встречу технических специалистов - они вам пригодятся так как вероятнее всего будут вопросы со звездочкой. И в обратную сторону - желательно попробовать выйти на контакт с техническими специалистами на стороне заказчика (особенно если они потом будут принимать разработку) и несколько раз проговорить реализацию, возможно добавить какие то тонкости, например, связанные с инфраструктурой и текущим технологическим стеком и стандартами разработки в компании заказчика.
Заказчики знают чего хотят, но не знают как это сделать, а исполнитель знает.
Обычно это говорит о том, что есть бизнес требования и их необходимо разложить на техническую реализацию. Тот самый момент когда исполнитель может проявить свой опыт максимально и предложить то тз которое ему будет удобно реализовывать - взять инициативу в свои руки
Конечно, если вопрос контракта еще нерешенный - не стоит открывать все карты.
Заказчики знают чего хотят, но не знают как это сделать, и исполнитель тоже НЕ знает.
Таких проектов довольно много у консалтеров широкого профиля - бывает под большие контракты набираются даже целые отделы.Тут нет смысла бороться за детальное ТЗ, вероятнее всего вы будете сами на ходу решать проблемы и погружаться в тему. Избегайте детализации, в которой ответственные стороны могут диктовать фиктивные требования только для заполнения документа. Попробуйте найти и привлечь на консультацию специалистов, имеющий опыт решения подробных задачи, пусть хоть и в роли ИП - но чтобы все таки зафиксировать референсные точки. Тут нужно делать упор не сколько на тз, сколько на процесс - множьте сроки по реализации контракта на 3, осознайте и договоритесь с заказчиком на итеративную выдачу результата и регулярную синхронизацию.
Заказчики не знают чего хотят, но слышали как сделал кто-то еще и делать нужно без вариантов - политика партии.
Звучит не очень, но бывает, что заказчику не страшно потерять время/деньги, для него это r&d задача и важен процесс - движение вперед, важно пробовать.
В этом случае - вы должны быть максимально проактивны и предложить то как вы можете и умеете делать, в этом случае вас вероятнее всего будут сравнивать - постарайтесь на этапе ТЗ понять по каким ключевым параметрам и их обговорить отдельно. Будьте готовы психологически к некой пассивности клиента, и взлету уже постфактум(но и это не всегда). В таком ситуации я бы постаралась максимально быстро и экономно для себя выдать результат и уже после работать с обратной связью.
Заказчик - ваш постоянный клиент. Имеется ввиду именно профессионально, а не друг/товарищ. Заказчик хорошо знает вас как специалиста и доверяет больше чем себе. В моей практике было такое - когда я сама себе писала целиком ТЗ - так как уже лучше заказчика понимала, что ему требуется, фиксировала все в документе, отправляла на согласование, дополнительно отдельно проговаривала. Все были счастливы и просили еще и еще.
ТЗ - Нужно записать. Не поверите но существует достаточно большая разница между талмудом на 60 страниц (например, гост на по проектированию АС) и аудиозаписью в ватсап.
Как я говорила ранее в зависимости от ситуации, разрабатывать детальные требования на ранних стадиях проекта иногда не требуется, но ТЗ должно быть задокументировано.
Мы живем в очень быстрое время, процессы ускоряются, доступные технологии - делают нас все более поверхностными в части любого текстового общения. Знаете как часто мужчины шлют смайлик “огонь” - вместо того чтобы написать, “ты красивая”, хотя нельзя быть уверенными, что правильная расшифровка фразы не “гори в огне, ведьма”.Так же и в вопросах передачи друг другу задач. Например, если говорить о ролях клиент-исполнитель, люди переносят свой быстрый опыт заказа уже готовых изделий, в котором достаточно 2х сообщений в мессенджерах или одного клика на сайте. Для таких продуктов, вероятно скорость действительно ключевой показатель успешности бизнеса. Но, когда речь продукт на основе данных, или выборе целого платформенное решение - это все-таки не коробочная история.
В ТЗ, практически как в CAP теореме можно обеспечить только два из трех пунктов:
- неистовая скорость в подготовке ТЗ
- индивидуальность настроек в решение
- отсутствие глобальной переработки продукта на более позднем этапе ЖЦ
Как запустить процесс написания ТЗ?
Ответ очень простой - коммуницируйте правильно с самого старта проекта!
Вся информация, которая получаться со встреч и различного рода других коммуникаций - уже часть технического задания.
Бич нашего времени в качестве этих самых коммуникаций.
Какие есть каналы и как выстраивать работу в них:
- Мессенджеры, в них текст не привязан к “теме” и конкретному проекту, часто отправлен в нескольких сообщениях и не “осмыслен”( сама периодически грешу таким). Просите важные тезисы дублировать в почту (они же уже все равно написаны) или делайте это сами, не стесняйтесь менять заголовки на осмысленные, просите коллег вести диалог в одной ветке, сохраняя тем самым историю переписки.
- Аудиозаписи - это вообще проклятие, думаю, тут не нужно пояснять - что человек не должен писать конспект по вашей 3х минутной речи. И более того он не может к ней вернутся в любой момент.
- Звонки - хорошее, просто отличное средство для коммуникации. Но так же обязательно подтверждать письмом в официальном канале, иначе :
- вас найдут когнитивные ошибки восприятия разными людьми разных аспектов (исполнитель по хорошему должен “пересказать своими словами” то что сказал заказчик)
- различия в восприятие времени и понятия “скоро”
- банально - кто нибудь потом не вспомнит и это не вопрос доверия, а того, что все мы довольно многозадачные
- текст обратит на себя внимание и позволит что-то уточнить, ведь его можно перечитать 3-5 раз
- если большая команда - вас ждет меньше испорченного телефона
- текст упрощает процесс делегирования
Просто собирайте результаты всех этих коммуникаций на какой-нибудь wiki странице, пусть аналитики и другие участники вашей - умеют к ней доступ и будут заряжены просматривать и задавать уточняющие вопросы.
В общем, с ТЗ в целом имеет смысл работать как с любым документом - сначала создаете структуру и наполняйте ее. Откуда взять структуру:
- Заведите шаблон вопросов по типовым проектам - если он у вас есть, главное не забывать обогащать острыми моментами каждого нового проекта. Как мы проговорили ранее, часто заказчик не знает ответов - но даже фиксация того - что этот вопрос не был учтен на ранней стадии - даст вам возможность запросить доп время и деньги - если что-то пойдет не так. Так же это поможет в целом осознать ситуацию и уровень зрелости и вовлеченности заказчика в проект(возвращаемся к 5 вариантам) . Еще лучше если в вашем шаблоне будут не только вопросы, но и варианты ответа - ограничивая выбор, имеете возможность обосновать вариант который наиболее важен вам в реализации.
- Возьмите за основу старый/похожий проект, даже если у вас такого не было - поспрашивайте у коллег.
- Если у вас совсем нет опыта, то попробуйте "приготовить рецепт до конца" - т е постарайтесь визуализировать себе процесс реализации поэтапно в проджект плане, обсуждая с техническими специалистами детали каждого этапа, по ходу у вас начнут возникать вопросы.
Тз это диалог, диалог это процесс.
Нужно понимать, что какой бы не была ваша методика ведения проекта/задачи, waterfall или agile, диалог не пройдёт за одну итерацию и будет продолжаться на всех этапах жизненного цикла.
Agile в свою очередь - это не разработка без требований - это разработка в которой требования могут законно меняться.
Все хотят agile, но часто люди в самих командах психологически не готовы к тому, чтобы после
определенной итерации менялись требования - чувствуют себя удрученно и их руки опускаются. Если вы готовы “бежать” не обсудив детали, будьте готовы бежать несколько раз.
В случае если речь о контрактных работах - вы должны в зависимости от уровня неопределенности и предполагаемого кол-ва “итераций” маневрировать ценой и сроками.
Можете погуглить в интернете множество статей на тему управления требованиями, это целая полка в проектном менеджменте со специализированными инструментами. (мне понравилась первая часть статьи https://habr.com/ru/company/ds/blog/534580/).
В общем, это целое искусство, перечислю несколько тезисов из моего опыта:
- Цените возможность задавать вопросы, но не давайте им ходить по кругу, только в случае неуспешности ранее принятых решений.
- Если вам нужно что-то “уточнить” используйте только четкие, утвердительные формулировки, желательно как в игре - да/нет - а не абстрактные филосовские вопросы.
- Задавайте “открытые” вопросы - только в случае если вам не критичен ответ, а так лучше опять же предлагайте варианты из вашей практики, заранее прикидывая дальнейшие ходы по этим вариантам.
- Даже после того, как ТЗ написано (и например, согласовано в официальном договоре, если это внешний клиент) не забывайте фиксировать дальнейшие требования на каких то опять же wiki страницах или в единой ветке письма.
- Еще интересный аспект - это оперативное реагирование на критические “уточнения”, нужно обязательно донести до всех участников команды, необходимость не только записывать, но и акцентировать на них внимание руководства. Кажется, это очевидно, но увы я сталкивалась с таким - что то нужно делать не по ТЗ выяснили давно и даже начали делать, а риски и сроки не оценили.
Что там по данным?
ТЗ на создание Платформы/Хранилища, в общем какой-то комплексной системы обеспечивающей решение сразу ряда задач. Тут можно смело гуглить стандарты проектирования АС и далее по моим инструкциям - выделять главное. Не берусь советовать больше, потому что во первых - я не архитектор, а во вторых это нужно еще 5 страниц написать.
ТЗ на витрину(data set - который будет использоваться в постоянных целях и возможно несколькими потребителями) - на эту тему написала целую статью и задала много всяких интересных и важных вопросов, которые можно использовать под структуру ТЗ. http://inoursky.com/helenlovedata/pochemu-vitrina-dannyh-eto-ne-odna-tablitsa
И еще не забудьте спросить про критерии приемки:
- чтобы понять какие показатели - ключевые показатели
- должны ли ваши данные с чем то сходиться или сходиться между собой
ТЗ на отчет ( разовое или многоразовая выгрузка готовых расчетов)
Тут я бы сфокусировалась на самой итоговой форме отчета - и в колонках же написать методологию в бизнес терминах и пример данных - это позволит понять, что вы не теряете какой то показатель и правильно понимаете гранулярность данных .
Почему не стоит боятся ТЗ не с точки зрения проекта, а с точки зрения каждого конкретного участника?
- в действительности это довольно творческий момент для всех участников процесса - а любить творчество нынче в моде
- вопросы озвученные в ТЗ все равно придется решать, просто выбора будет меньше, участники возможно будут воспринимать это как “проблемы” /”исправление ошибок” - грустить и уставать - снижайте уровень стресса
- записывание информации - позволяет осознать и структурировать, декомпозировать задачу, это полезный soft/да и hard скилл( и главная причина - почему я веду этот блог)
Не могу не оставить тут одну из миллиона картинок на эту тему. Она о том, что проблемы, связанные с ошибками разработки или производства, зачастую весьма несущественны по сравнению с теми, что заложены в требованиях.
Повторюсь, чтобы все это имело смысл не забывайте, что необходимо выстроить систему работы таким образом чтобы не только писать, но и читать ТЗ . Оно должно быть на виду и общим рабочим инструментом.
Всем спасибо, i love data