Привет, меня зовут Антон Фокин, я CEO студии QTIM, занимаемся заказной разработкой. Сайты, приложения, цифровые сервисы, вот это вот всё. Статью мне помогал писать Артём Трушин, наш CPO. Расскажем, как мы выкинули написание ТЗ из наших процессов и сократили среднее время на разработку проектов в 4 раза.
Почему мы отказались от технического задания
Причина 1. Его редко используют на 100%
Зачем пишут ТЗ? С ним клиенты чувствуют, что они защищены: есть документ — значит, мы должны получить определенный функционал. На практике от этого функционала остается буквально 30 процентов, в лучшем случае 40. Остальное замещают доработки, новые идеи и неучтенные моменты, которые всплывают в процессе.
Когда речь идет о цифровых продуктах, которые несут ценность сами по себе (например, мобильное приложение для аренды летающих электросамокатов), то ТЗ почти всегда окажется в мусорке. Потому что продукт живой, а значит, и писаться должен итеративно. Если речь о корпоративном сайте ООО «Заптехросгосснаб» — то не вопрос, можно спроектировать его заранее, написать ТЗ и сделать строго по нему.
Причина 2. Никто ничего не знает наверняка
У меня был кейс с маркетплейсом: клиент хотел площадку с безопасной сделкой. Начинаю, делаю, когда дохожу до неё, оказывается, пеймент флоу, по которому заказчик хотел работать, не реализован ни у одной платежной системы. Хотя компании пиарятся, что всё это уже есть. Пришлось переделывать по новой.
Когда ТЗ столкнется с реальностью, оно почти наверняка разобьется всмятку. Потому что рынок, пока вы писали техзадание, поменялся, появились новые технологии или сервисы. Или сервисы, наоборот, сделали ручкой и стали недоступны.
Причина 3. Это пожиратель времени
Написание ТЗ — это долгий процесс, который занимает около 25% от общих сроков проекта. Ну, по крайней мере, в нашей с Артёмом вселенной это так.
Проинтервьюировать заказчика, написать техзадание — это еще только половина приключения. Потом будут согласования и корректировка. Согласования имеют свойства затягиваться: заказчик будет читать, проверять, пытаться всё сразу предусмотреть. Но так не бывает. В большинстве случаев клиент до конца не знает, что хочет получить в итоге (см. причину 2).
Причина 4. Это шоустоппер
Работал с одним клиентом, техзадания писались по два месяца. Проект уже мог идти полным ходом, но без готового техзадания не двигался с места.
При этом процессы подрядчика-разработчика тоже стоит учитывать. При загрузке, близкой к полной, вы вряд ли будете холдить команду под проект, который два месяца ждет согласования ТЗ. Когда все подпишут — потребуется время на запуск, ты будешь ждать нужных специалистов с других проектов. А промедление смерти подобно, как известно.
Причина 5. Пока ты пишешь ТЗ, у клиента все поменялось внутри
Не в его богатом духовном мире, а в рабочих процессах. Произойти может масса всего, например, клиент перейдет на другую CRM или систему складского учета, или еще что-нибудь. Все ваши предусмотренные интеграции резко станут неактуальными и тебе придется их пересчитывать и переписывать. Время, время.
Причина 6. Клиент не высказал всего, что ему нужно
Техзадание обычно пишет не ЛПР и не product owner. У него на такое нет времени. ТЗ пишет выделенный под это человек. Он собеседует и интервьюирует клиента, а потом пишет все, что услышал. Но самые нужные слова приходят на лестничной клетке (ну или в лифте), так что за рамками ТЗ остается целый запас того, что подразумевалось, но не проговаривалось вслух.
Итого. По моему опыту, при работе с ТЗ теряется 60–70% функционала, изначально описанного в документе. Это происходит из-за новых идей или неучтенных моментов, которые возникают в процессе разработки. Отступать от ТЗ приходится в любом случае. И на ТЗ уходит до четверти всего времени, заложенного на проект. Мы с Артёмом подумали: ну его нафиг.
Быстрее в 4 раза: как мы строим процесс теперь
Все-таки наши рабочие процессы даже без ТЗ далеки от хаоса. Вот так мы с нашим CPO все устроили.
Первый этап: разработка пользовательской истории
Клиент представляет обычную user story в формате «я хочу, чтобы при нажатии этой кнопки открывалась история заказов».
Например, PowerApp — приложение с шарингом зарядных устройств. Из пожеланий в нем должны быть процесс аренды, гибкие тарифы, современные способы оплаты: СБП, Yandex Pay и так далее. С помощью уточняющих вопросов я собрал wireframe в одно пространство — матрицу, из которой уже формируются макеты.
Второй этап: отрисовка макетов
Отдаю матрицу дальше. Дизайнеры вместе с менеджером проекта продумывают пользовательские сценарии — получается CJM. Они обсуждают, как всё должно работать, и на ее основе отрисовываются макеты.
Я призываю команду смотреть на задачу с точки зрения пользователя — и описывать, как сайт или приложение должны работать с его стороны. Если выгрузить все задачи из ClickUp, по сути получится ТЗ — но оно не пишется заранее, а формируется в процессе: описывается, редактируется, обсуждается. Получается такая проектная документация.
Кроме того, нет техзадания на весь проект. Оно пишется под каждый спринт, не досконально про каждую кнопку, а про основной функционал, ссылки на макеты и договоренности с клиентом. То есть есть доказательства того, о чем мы договаривались.
Третий этап: frontend и backend-разработка
Разбитые на спринты по две недели. Каждый спринт я отдаю клиенту часть функционала на тест, чтобы сразу свериться по вопросу «ожидание/реальность». При этом работаю в режиме «спринт плюс один». Общее понимание этапности и результата есть, но оно меняется в реальном времени — часто я не знаю, какой модуль будет лучше взять чисто по кодовой базе.
Один из клиентов ближе к концу проекта попросил составить полную документацию, и мы с Артёмом взяли на это целый спринт — примерно 100 часов. И описывали весь проект. Если каждый разработчик после написания своей задачи будет все документировать, будет очень классно и правильно. Но на неё уйдёт четыре недели вместо двух.
Четвертый этап: работа с багами
Фикс багов — отдельный спринт, под который заложен бюджет и время. Я всегда обсуждаю с клиентами процент багов. Чаще всего сразу проговариваем, что баги будут после каждого этапа — но фиксить я их буду в последнем спринте, потому что работаем быстро. У меня есть условные пять месяцев и нет времени доводить каждый этап до совершенства.
Как это работает на практике
Клиент: онлайн-школа.
Задача: выпустить собственную платформу с функционалом iSpring за 5 месяцев
QTIM был не первой командой, к которой обратился клиент. Другой подрядчик работал над проектом полтора года — при наличии техзадания — и не доделал его до конца. Я же начал работать без ТЗ по модулям — и сделал платформу за пять месяцев.
В процессе менялись какие-то модули, получалось полностью по-другому относительно того, что клиент хотел изначально. И так три раза. Если бы работали с ТЗ, приходилось бы переписывать его каждый раз, согласовывать, пересчитывать стоимость проекта. Пять месяцев превратились бы в десять, год, полтора — то, что случилось с первым подрядчиком.
Я брал в два спринта задачи, которые мог показать и сдать. Например, берем 30–40% бэкенда, которые никто из клиентов не смотрит. К концу этапа должен быть результат, который они посмотрят, проверят — и увидят, что проект продвигается. Таким образом, клиент каждый месяц получает определенную ценность.
С точки зрения финансирования это выглядит так. Условно, проект стоит 5 миллионов и длится 6 месяцев. В среднем мне платят по 800 тысяч в месяц. Сначала отдают 400, а следующие 400 отдадут, когда убедятся, что я выполнил задачи на этот спринт. Клиент вносит постоплату, и я перехожу к следующему этапу — и так далее.
Так мы с клиентом движемся к последнему этапу: основной функционал работает, баги пропускаем и складываем их в общую таблицу — фиксим в последний месяц. Это всегда проговаривается. Конечно, если у клиента есть запас времени, лучше фиксить баги сразу.
Но есть нюансы. Что нужно учесть при отказе от ТЗ?
Формат, в котором я работаю, подходит не всем. С одной стороны, получается быстро, без бюрократии. Но у всего есть обратная сторона. Вот к чему нужно готовиться, если вы хотите перевести свою команду на такой подход.
Клиенты не всегда готовы работать без ТЗ
Многие клиенты считают, что ТЗ — это мастхэв, без которого нельзя. Это как когда к вам приходят и просят сделать интернет-магазин на Битриксе. Почему на нём? Потому что клиент не знает, что есть масса других решений, которые подходят ему больше. С техзаданием та же история: обычно у всех есть знакомый разработчик, который советует обязательно составить ТЗ. Придется переубеждать. Хорошо работают частые демонстрации промежуточных результатов — а когда проект готов на 65%, клиент обычно успокаивается и доверяется тебе.
Может быть сложно оценить проект
Часто во время работы возникают дополнительные расходы. Важно оценить риски сразу. Я иду навстречу и действую в интересах клиента и его бюджета. Если понимаю, что делаю что-то не то, просто останавливаюсь и делаю другое. Оцениваю ситуацию быстро: не бывает такого, что растягиваю на несколько недель.
Без ТЗ невозможно дать идеальную оценку, поэтому оцениваю вилкой. Например, клиент говорит, что хочет маркетплейс с такими-то функциями. Я называю примерную стоимость, исходя из свого опыта. Считаем, сколько надо выделить человек в команду: фронта, бэка, дизайнера, менеджера — умножаем на рейт, примерный срок, получаем вилку. В процессе требования уточняются и картина становится более четкой. Обычно, если приходится выходить из бюджета, сообщаю об этом клиенту заранее.
Вам понадобится экспертная автономная команда
Чтобы работать без ТЗ и понимать, что хочет клиент, нужна сильная экспертиза. Каждый член команды важен, никто не передает недоделанную или сделанную плохо работу дальше по цепочке. Все без исключения понимают, какие задачи бизнеса они выполняют своей работой. В этом процессе особую роль играют менеджеры проектов — они дирижеры, которые переводят бизнес-задачи клиента на технический язык. У меня проджекты работают в парах с дизайнерами — следят за тем, чтобы все было идеально учтено еще на первых этапах. Дальше — они выполняют контролирующую функцию, тестируют продукт по юзкейсам.
А коммуникация внутри команды идёт без них. Работать без ТЗ можно только в таком формате. Если люди не умеют самостоятельно решать вопросы, это гиблое дело.
Нужны сильные думающие дизайнеры
Момент, которому, на мой взгляд, уделяют недостаточно внимания. Хорошие дизайнеры работают с проджектами, продумывают пользовательские сценарии, учитывают все моменты — что и как будет работать. Если дизайнер с менеджером всё продумали, вы быстро согласуете макеты с клиентом и отдадите их в разработку. Продумывайте все вплоть до каждой иконки. Как и в каких случаях она будет себя вести?
А вы всё ещё к̶и̶п̶я̶т̶и̶т̶е̶ пишете ТЗ? Пишите о своих процессах в комментариях или мне в Telegram.
Комментарии (90)
theoll
22.09.2023 18:21+6ну хоть бы опрос дали, конечно тз важен, в лендинги может и не нужен или где можно наговнякать, а так да заказчик всегда барин и если можно с ним договорится что лучше сделать "а" чем "б" но это не отменяет того факта что сделается адекватный тз с пожеланиями клиента и который заапрувили разработчики, иначе у вас рано или поздно вылезут какието конфликты или по срокам или по оплате, а эти "наши супер дизйнеры, синьеры и етц держат нос по ветру и так знают как им делать" это вобще печаль в нормальной разработке
foxijke Автор
22.09.2023 18:21Это наш опыт о котором мы решили рассказать не через 1 или 2 проекта, а когда сделали уже с 2 десятка
Изговнякать можно что угодно
Но когда цель выпустить продукт в срок и нормального качества, то проще все решать с клиентами по факту
Лендинги мы не делаем, мы занимаемся только большими проектами. Так что если в команде хорошо выстроены процессы и есть толковые люди, то будет успех, а если все в носу ковыряют, то и с тз можно знатно обкакаться.
hVostt
22.09.2023 18:21+3В том-то и соль, это ваш опыт. Часто причину путают со следствием. Причина успеха не способ организации команды, а сама команда. Как следствие, команда эффективней быстрее вот так (без ТЗ).
А теперь представьте абсолютно рандомную команду. Т.е. вам известен количественный состав и уровень (честный). Будет ли всё работать также?
Отсюда очень сильный перекос менеджмента в сторону процессов. При чём зачастую на фоне важности этих процессов люди растворяются и превращаются в безликий ресурс.
Когда в команде: толковые ребята, они друг с другом на одной волне, всем комфортно по основным направлениям, то подойдёт любой процесс, который не будет им мешать. Замечу. Не помогать, -- не мешать.
Emulyator
22.09.2023 18:21Намек на то, что требование ТЗ должно настораживать заказчика, ведь возможно он попал на рандомную команду безликого ресурса, а не на толковых ребят работающих на одной волне? )
hVostt
22.09.2023 18:21+1Какой же намёк? Вы рассказываете, что с ТЗ плохо, а без ТЗ хорошо. А дело вовсе не в ТЗ.
Ещё неизвестно, что вы вкладываете в понятие ТЗ. Это должен быть талмуд на 1000 страниц, описывающий в деталях взаимодействие фронтенд-бекенд? Или ТЗ всё же, это ожидания заказчика? И что плохого или сложного, чтобы договориться на берегу. Что заказчик ждёт, за что платит, когда он это получит, и будет ли результат соответствовать его ожиданиям?
Может вы от ТЗ никуда и не уходили, просто тот набор артефактов, с которым вы оперируете почему-то не дотягивает до вашего понимания "ТЗ"?
В общем, всё очень странно. Если команда находится внутри компании-заказчика, работать мелкими итерациями по аджайлу удобно и комфортно. Если же это аутсорс, то за что платить деньги? Если нет зафиксированных ожиданий в виде ТЗ, за что платить? Как фишка ляжет? Это настолько офигенная аутсорс команда, что всё на полном доверии, и оплачивается просто время, а не получаемый результат? :)
Вопросов больше чем ответов. Договорные отношения как выглядят? Мы не знаем что мы для вас сделаем, мы не знаем чего мы хотим, но это вот столько стоит, потому что "ребятам надо что-то кушать" :)
foxijke Автор
22.09.2023 18:21Про намеки писал Вам не я )
Ваше право иметь другую точку зрения. То что работает у нас возможно не сработает в других командах. Все люди разные, поэтому каждая точка зрения в том числе ваша имеет место быть.hVostt
22.09.2023 18:21+1О, извините :) Не обратил внимания, что комментарий не авторский.
Но отвечу вам. Мне кажется писать кому-то о том, что он имеет право на другую точку зрения несколько странно. Как будто мне великодушно позволено мыслить иначе. Спасибо огромное! Прям камень с души. А то вдруг нельзя, и на меня заявят в органы :)
Но вопрос остаётся открытым. Либо вы под ТЗ понимаете что-то уровня ГОСТ-документации со всеми болтиками-винтиками, вплоть до количества строк кода и сколько байт будут занимать бинарники и контент. Либо это просто выглядит очень странно. При чём тут вообще точка зрения? Договорные отношения в государстве не должны быть субъективными.
А то, я приду к вам, заплачу. И скажу. По моей точке зрения, вы сделали не то, не так, стоит оно не столько, и вообще мне всё не нравится. Верните деньги пожалуйста.
Что будем делать? У нас ведь нет никакого ТЗ, ребята просто что-то там делали, и выдали какой-то там результат. Мне такой результат вообще не понравился. Вы потратили моё время, также нужно ещё возместить за потраченное время.
Просто интересно, как это у вас работает?
foxijke Автор
22.09.2023 18:21У нас есть описание в доп соглашении чтт заказчик получает на выходе
Для этого не обязательно писать ТЗ, и да у нас понимание ТЗ именно ближе к ГОСТУ так как есть проекты близкие к госам
Язвить кстати не обязательно про точки зрения, я лишь хотел сказать, что если у кого то не работает, как у нас, то это не значит что вообще ни у кого не заработает
SpiderEkb
22.09.2023 18:21Ещё неизвестно, что вы вкладываете в понятие ТЗ. Это должен быть талмуд на 1000 страниц, описывающий в деталях взаимодействие фронтенд-бекенд? Или ТЗ всё же, это ожидания заказчика?
Я уже писал ниже (или выше?) - ожидания заказчика - это BRD. ТЗ - FSD. Первое есть согласованный с заказчиком документ (в принципе, с ним можно и в суд если возникнут разногласия на этапе сдачи-приемки-оплаты), второе - чисто внутренняя документация команды в любой удобной ей форме.
Лично я даже "непроектные", технические задачи не делаю без предварительного планирования - понимания как это будет выглядеть, как использоваться, каковы основные сценарии, граничные условия и т.п. Пока всего этого нет, нет понимания что именно нужно делать и как. Потому что переделывать все 10 раз просто потому что изначально чего-то не учел у меня просто времени нет - все техническое-непроектное делается в "свободное от работы время". Которого катастрофически мало.
vanzhiganov
22.09.2023 18:21+4У меня был кейс с маркетплейсом: клиент хотел площадку с безопасной сделкой. Начинаю, делаю, когда дохожу до неё, оказывается, пеймент флоу, по которому заказчик хотел работать, не реализован ни у одной платежной системы.
Получается, вы не анализировали ТЗ перед тем как начали что-то делать?
foxijke Автор
22.09.2023 18:21+1Анализировали
я вам больше скажу, мы даже перед стартом работ с платежклй общались и доку читали
Оказывается доку ребята написали, продажнику ее отдали, ток запилить все забыли и сказали ждите 6-12 месяцев )
vanzhiganov
22.09.2023 18:21+3А, ну это классика :) но думаю надо было написать, а то непонятно.
foxijke Автор
22.09.2023 18:21+1Да, такие случае действительно не единичные )
Благо обычно на первых порах это видно
А с этой платежкой уже последние пункты были не работающие )
MiraclePtr
22.09.2023 18:21+2Собственно, я именно об этом недавно и писал в комментариях к срач-посту про гибкие методологии:
Во-первых, сейчас мир очень ускорился и очень переменчивый. Как уже сказано, за то время, что вы что-то пилите "от и до", ситуация может измениться значительно - конкуренты выкатят какую-то этакую киллер-фичу или революционную идею, изменятся требования законодательства, да и куча всего другого может изменится - и конечный продукт по тем требования/спецификациям, то вы утверждали в начале разработки, будет уже просто никому не нужен.
Во-вторых да, тут известная проблема с заказчиками: клиент приходит к вам со списком хотелок, которые условно говоря сформулированы на 5 страницах. Потом бизнес-аналитики и менеджеры это все дело внимательно читают, задают вопросы, смотрят как что сделано у конкурентов, разговаривают с разраьотчиками, сверяются со стандартами, и т.д., в итоге превращают эти 5 страниц требований в 50 (а то и в 150), и отдают это ТЗ обратно заказчику на согласование. Проблема в том, что закзачик практически всегда это итоговое ТЗ или особо не читает, или читает, но при этом все равно представляя какую-то картину, которая у него была с самого начала в голове, натягивая на нее все написанное. И когда после долгого времени разработки по утвержденному ТЗ все готово, то... оказывается, что нужно было вообще совсем другое. И заказчик в печали. Разработчики, кстати, тоже будут демотивированы - так долго делали, столько старались, а в итоге результат всей этой работы придется выкидывать и переделывать. Можно, конечно, сказать заказчику, мол, сам дурак, какое ТЗ такой и результат, сами утвердили и подписали, вот только заказчики от этого не изменятся, а просто пойдут со своими мешками денег к тем, кто более гибкий (неспроста Agile - это именно "гибкие" методологии), а вы останетесь без заказов. А "гибкие" товарищи гораздо быстрее адаптируются - склепали быстренько прототип, показали клиенту, приняли отзывы и правки, доработали, пошли пилить дальше. И все довольны.
AndrewYaremko
22.09.2023 18:21+4Ага, выучили слово ТЗ и давай по нему работать, а то что сначала пакет документации надо разработать в виде UX стратегии, информационной архитектуры, блюпринта и как следствие пак ТЗ под конкретные составояющие, это нет — долго и дорого. Я от ТЗ отказался в угоду документации, графической и видео, да сижу по таймлайну отмечаю где для дизов инфа, где для тех директоров.
sukhe
22.09.2023 18:21+6Я забодался после вас переделывать. Не конкретно вас, а вообще. После таких умельцев, которые без ТЗ код фигачят.
foxijke Автор
22.09.2023 18:21+4Аналогично, вы не представляете сколько мы переделали за теми кто писал с ТЗ. ))
Может дело не в тз, а в кривизне рук. А если они кривите, то никакое тз не спасет
zikkuratvk
22.09.2023 18:21+12Хех... а вы пробовали без ТЗ автоматизировать хоть, сколько нибудь сложный бизнес процесс. На самом деле тз нужно заказчику, чтоб понять, что он хочет. На этапе проработки задания, как правило задача аналитика утрясти процесс не только для разработчиков, но и для клиентов.
Для примера:
Как звучит процесс для руководителя бизнеса. Мы получаем прибыль с продажи.
Для отдела логистики. Мы отправляем грузы по складам и заказчикам.
Для отдела скажем продаж. Мы выполняем планы по продажам.
И так далее в зависимости от того, куда вы придёте у всех будет разное виденье процессов и скорее всего ни один человек в компании не будет знать, как в реальности продается товар. Все видят свою маленькую часть, ньансов смежников могут не знать, а часто они вообще не представляют, что творится у его же сотрудника за соседним столом.И вот вы такие пришли хорошие и сделали как вам сказал скажем начальник отдела продаж... а потом выяснилось, что интересы других вы не учли вообще... и да вы быстро сделали молодцы :-) но потом 10 раз переделали. Я просто сейчас наблюдаю, как менеджеры бьются за сокращение проработки заданий на разработку, но экономя 10% времени, они часто тратят +100% времени разработчика. За то да шороху наводят знатного...
И ещё чем меньше по объему задача, тем она как правило понятнее и прогнозируемая по времени исполнения... но чтоб эту задачу декомпозировать на много мелких... нужно понимание общей задачи.
Опять же судя по всему вы решаете достаточно типовые для вас задачи, в таких случаях может быть и прокатывает.foxijke Автор
22.09.2023 18:21+1Отлично описали, только все эти этапы мы проходим с каждым руководителем, поэтому имеем довольно полную картину. Задачи типовыми у нас не назовешь, мы разработали уже почти с десяток онлайн-школ и одна из них входит в топ-2 России в сфере школьного образования.
Кол-во персонала сократилось, учитывая что многие процессы были автоматизированы
В штате сейчас у них больше 1тыс человек.
И кстати, мы там ничего ни разу не переделали. :)
zikkuratvk
22.09.2023 18:21+1Вы гении :-) либо чего то очень сильно не договариваете. Если бы я не участвовал и не был свидетелем нескольких сот проектов я бы может и поверил :-) не бывает такого, чтоб не переделывали...
При таких подходах заказчик ищет правильный путь путем экспериментов, то есть он сам не знает конечный результат. А значит вы приходите на сессию скажем с начальником отдела, он вам говорит одно, потом при проверке выясняется, что нужно было другое, это по ТЗ то регулярно происходит. А в таких процессах разработки просто могут сказать, мы тут подумали и решили, что надо все по другому. Делаем вот так. Я даже могу сказать почему, потому что заказчик не скован конечными требования, и полет фантазии обычно не ограничен, плюс не заставляет его выяснять на первых этапах, как работает тот или иной процесс. Это с одной стороны не плохо, позволяет быстро сделать mvp и проверить гипотезу с другой стороны часто ведёт к растягиванию разработки и ухудшает качество кода.
foxijke Автор
22.09.2023 18:21+1Если это считать переделками, то мы переделываем. Если меняются требования заказчика то хоть с ТЗ хоть без ТЗ переделывать придется.
А если разработка идет по ТЗ то как правило останавливается разработка, все снова по новой анализируется и прописывается, как юридически, так и само ТЗ.
iig
22.09.2023 18:21Если меняются требования заказчика то хоть с ТЗ хоть без ТЗ переделывать придется.
Черный цвет недостаточно черный, и давайте поиграем со шрифтами.
MaksimMukharev
22.09.2023 18:21+1А как в этом помогает ТЗ? По факту, оно будет согласовываться невероятно долго или, как обычно, часть руководителей передаст ответственность на кого-то другого. В момент приемки все это всплывёт в виде несоответствия с реальными бизнес-процессами и исполнитель будет вынужден отстаивать свою позицию на основе подписанных документов. Ситуация может легко измениться и со сменой одного из руководителей. При итеративный разработке остаётся больше степеней свободы, чтобы это учесть и подстроиться.
zikkuratvk
22.09.2023 18:21+3Собственно для этого и нужны аналитики, чтоб собирать пазлы.
Давайте по другому рассмотрим вопрос на примере дома. Можно ли дом построить без проекта? Частный жилой дом, да наверное можно. Многоквартирный - невозможно.
Давайте смотреть на разработку ПО. Можно ли написать по которое реализует бизнес процесс не понимая как он работает? Да можно... но вы будете всегда возвращаться на несколько шагов назад, чтоб что-то подкрутить, что то исправить, что то доработать, так как тут мы несли что в этом справочнике нужны такие данные, тут нам надо получить данные из других систем потому, что мы не знали, что они нужны вообще, мы о такой системе даже не знали. На выходе может получится Франкенштейн. Работать будет, возможно, но не факт, что хорошо.
Теперь представим что мы делаем какую нибудь систему которая объединяет много бизнес процессов:-) вот тут мы сталкиваемся с тем, что цели ещё более размыты, а иногда при итерационной разработке даже толком и не известны. И вам надо паралельно разработать 5 таких процессов. Знаете какая боль будет? А ведь там менеджеры проекта могут даже не задать вопрос зачем это мы делаем. Я видел как до 50% конечного продукта после этого выкидывалось, хотя тут надо сказать и видел как продукты разработанные по ТЗ выкидывались. Но тут суть не в этом в результате мы можем получить какую то кашу, которая неизвестно как работает и неизвестно отвечает ли настоящим требованиям заказчика.foxijke Автор
22.09.2023 18:21+1Не совсем корректное сравнение. Дом это как правило законченный проект, который должен прийти к логическому завершению, иначе это называется долгострой, что в нашей стране запрещено )
Проекты, особенно большие, это как правило процесс бесконечный. Компания растет, приходят новые люди, выстраиваются новые процессы и тд.
От каши спасает как правило документация, в которой все описано.
zikkuratvk
22.09.2023 18:21+1Из моего опыта все же работают комбинированные подходы, когда нам ясны процессы, но не проработаны до деталей, они и становятся нашим первоначальным ТЗ. Потом когда мы уже опускаемся на уровень реализации действий, мы уже делаем итерации иногда настолько мелкие, что задача может для разработчика составлять 1-3 дня. Таким образом мы можем прогнозировать, что она завершится в обозримые сроки, он ее поймет и даже если постановщик накосячил цена ощибки будет минимальная. Когда мы нарезаем задачи даже в 5 дней, уже возникают проблемы с прогнозами реализации задачи.
foxijke Автор
22.09.2023 18:21-3мы стараемся бить задачи на 1-2 дня для разработчиков
Для клиентов все выглядит по другому. И внутри компании у нас недельные спринты начинающиеся со вторника, так как если разраб не успевает закрыть за неделю задачи, то у него всегда есть выходные чтобы нагнать.zikkuratvk
22.09.2023 18:21+4Не хотел бы я у вас работать :-)
propell-ant
22.09.2023 18:21У одного крупного производителя форточек из города Редмонд задачи разбиваются до размера в 4 часа. Я, например, своим джунам всегда говорю: два часа тупишь без продвижения - зови старшего. Если задача на неделю, то можно и пару дней тупить.
Так что рабочий процесс у всех разный, размер задачи зависит от многих факторов.
MiraclePtr
22.09.2023 18:21+4если разраб не успевает закрыть за неделю задачи, то у него всегда есть выходные чтобы нагнать.
Я очень надеюсь, что вы сейчас пошутили. Если нет, то искренне сочувствую вашим работникам.
И кстати, не существует понятия "разработчик не успел", это называется "менеджер ошибся в оценке сроков". Это я вам как техлид говорю.
foxijke Автор
22.09.2023 18:21-1Менеджер ошибся в оценке сроков?)
Очень жаль ваших менеджеров если им приходится делать оценки, у нас это происходит совместно с разработчиком где он под это подписывается
Это я вам как собственник говорю ))
MiraclePtr
22.09.2023 18:21+4у нас это происходит совместно с разработчиком где он под это подписывается
Ну да. Разработчик говорит "чтобы сделать это потребуется три дня, если никакой фигни не случится", а обязанность менеджера - зная, что фигня случается, а разработчики имеют свойство оценивать задачи чрезмерно оптимистично, умножить это значение на определенный коэффициент (некоторые умножают на полтора, некоторые на число пи, в зависимости от специфики проекта и предыдущего опыта, некоторые по скраму считают все в стори-поинтах и вычисляют перформанс команды и конкретных ее членов).
О том и речь, что риск того, что "исполнитель не справится" должен закладываться в оценку сроков.
foxijke Автор
22.09.2023 18:21Так мир не идеален, такое может и бывает в 1 из 50 задач, но это не носит массовый характер
Вы же это преподносите так будто у нас люди 24/7 пашут, а это в корне не так
У нас штат 50+ человек, уволилось по собственному за 6 лет человек 5 всего
По-моему это о чем-то да говорит
zikkuratvk
22.09.2023 18:21+1Угу особенно учитывая, то что обычно закрытие задачи зависит минимум от двух людей. От постановщике и исполнителя. То есть если постановщик недоработал, то исполнитель пожертвовал своими выходными :-)
foxijke Автор
22.09.2023 18:21То есть то что исполнитель не справился не рассматривается ?)
Да и у нас в компании это носит исключительный характер а не массовый
boldMahoney
22.09.2023 18:21+4то что исполнитель не справился не рассматривается ?
Странно звучит, учитывая выше ваши громкие заявления:
Каждый член команды важен, никто не передает недоделанную или сделанную плохо работу дальше по цепочке. Все без исключения понимают, какие задачи бизнеса они выполняют своей работой
Такие заявления подразумевают найм исполнителей уровня сильно выше среднего, чтобы обладать навыками аналитика, менеджера и разработчика\дизайнера в одном лице. В таком случае исполнитель может не справиться с задачей в срок только если ему не дали исчерпывающей информации или она была некорректная (не берем в расчет факторы самого исполнителя: заболел\забухал\запрокрастинировал, для high-grade спецов такое недопустимо). А раз такое случается, то это явный косяк управления. Либо же вы лукавите и нанимаете зеленых юнцов с горящими глазами, но малым опытом, которые не могут на лету придумывать реализацию лишь по одной бизнес-хотелке в силу отсутствия опыта в таких задачах.
Ваш кликбейтный заголовок работает лишь для очень ограниченного скоупа работ, в ограниченном домене бизнеса и с очень крутой командой. Без этого проекты будут обречены на провал. К примеру я работаю на бэке в "кровавом энтерпрайзе" и у нас без ТЗ результат не то что не ХЗ, а его вообще не может быть. У нас заинтересованных (и не очень) сторон владельцев систем, которых затрагивает очередная модификация нашей системы может быть цать штук. И со всеми надо договориться, согласовать документы и сроки. У вас ТЗ составляет до 25% от объема проекта, а у нас вся первичная документация до 50% всех трудозатрат проекта, реализация лишь порядка 20%, тестирование еще 20%, остальное это нецелевые потери ТДЗ. У вас можно без ТЗ придумать и реализовать на ходу новый бизнес-процесс по продаже товара из корзины, выбору нового партнера доставки, проведению чекаута и его финальной оплаты через новую платежку. Оформление страниц, шрифты, цвета и надписи кнопок не столь важны. Потому как вам известен финальный пункт - проведение платежа и известны промежуточные этапы. У нас же в рамках одной интеграции с партнером может быть один-пять-цать бизнес-процессов. И часто бывает что бизнес-процессы похожи в коде, но различаются по сути. К примеру есть два разных канала приема сообщений от партнера, два бизнес-процесса помимо многих прочих, но внутри нашей системы они выглядят в коде одинаково, одинаково обрабатываются и складываются в одну и ту же таблицу БД. И надо добавить функционал: при ответе партнеру на его сообщение, добавлять еще и вложения скачанные из двух разных смежных систем в зависимости от канал приема (сканы подписанных бух доков). И ответ надо отправлять через тот же канал, откуда пришел изначальный запрос. Вопрос в какой бизнес процесс это добавлять если в коде он един? И на каком этапе обработки? Без ТЗ все это выяснить читая лишь один код крайне затруднительно (а подчас невозможно). И это лишь самое простое, а в нашей области такое сплошь и рядом. Это результат n-лет эволюции функционала систем, понятно что с нуля так никто писать не будет. И когда мне приходит очередная задача на разработку в бизнес-процессе который я ранее не знал, я ищу все ТЗ в нашей knowledge-base касающиеся сабжа и читаю описания что, куда и зачем. Только так можно понять и реализовать то, что требуется. Да у нас тоже бывают факапы, когда приходится работать на выходных. Но это исключительная ситуация, случается 1<= в год и полностью оплачивается т.к. руководство понимает, что это их прокол. Ситуаций когда разработчик "не успел" и вынужден работать на выходных за свой счет не должно быть и в хороших фирмах не практикуется.
foxijke Автор
22.09.2023 18:21Именно, факапы случаются и выходные оплачиваются если это действительно не факап по причине самого спеца
За свой счет в выходные работают только те кто по своей же вине не успел сделать это в будни, разве это не справедливо?
MiraclePtr
22.09.2023 18:21+2За свой счет в выходные работают только те кто по своей же вине не успел сделать это в будни, разве это не справедливо?
Тут такой вопрос - а у вас разработчики трудоустроены по трудовым договорам, или же по договорам подряда? Иными словами, по действующим конктрактам между работниками и вами как работодателем вы им платите за рабочие часы, или отдельно за закрытие каждой задачи?
foxijke Автор
22.09.2023 18:21И еще вы сравниваете продуктовую и заказную разработку
Тут есть разница
Судя по вашему описанию у вас продукт который существует уже не первый год
ibragim091986
22.09.2023 18:21+1С помощью ТЗ удобнее ориентироваться что делать и как делать при разработке и не надо каждый раз дергать заказчика с вопросами "а тут как сделать, а тут так подойдет?". Взял ТЗ и написал код, делов то )
foxijke Автор
22.09.2023 18:21-1Есть ощущение что у вас одеты розовые очки через которые вы смотрите на этот мир )
Если бы все так было просто…
propell-ant
22.09.2023 18:21+3Забавно, но читателям вашей статьи точно так же может показаться, что автор в розовых очках.
Вы работаете в своей нише, где исполнителям ясны их задачи, а заказчиков устраивает процесс и результат. Вы молодцы, что отбросили ненужные формальности. Но вокруг полно других примеров, народ в комментах пишет об этом.
foxijke Автор
22.09.2023 18:21Возможно, просто наша практика показала что отклонений от тз слишком много и в нем нет смысла
iig
22.09.2023 18:21отклонений от тз слишком много
Так ТЗ это не закон сохранения энергии, его же можно и подкорректировать.
ЗЫ Интересные у вас заказчики. С одной стороны забюрократизированные до крайностей, и без нескольких месяцев согласований ТЗ все равно не будет. С другой стороны, просто берут и принимают результат работы, без никаких формальностей.
kinall
22.09.2023 18:21+5Похоже на манифест "Пиши код б@#&!". И есть ощущение, что это хорошо работает на приложениях для самокатов и бизнес-софта мелких фирмочек, а сломается на чём-то сложном, вроде системы учёта в масштабе завода.
foxijke Автор
22.09.2023 18:21За 2023 год уже запущено 5 онлайн-школ с разными бизнес процессами. В одной из них 20к+ пользователей
Все довольно хорошо работает.
На счет самокатов, я кстати с вами не соглашусь, там не все так просто. Попробуйте поработать с китайскими протоколами на основе которых работают платы. Я думаю вы поменяете свое мнение.boldMahoney
22.09.2023 18:21+1Ряд проектов онлайн школ (не айтишной тематики) которые я видел (знакомые просили распарсить и слить видео-курсы для личного архива), не отличаются оригинальностью и в целом сильно похожи. Думаю после 5 сданных проектов можно хорошо набить руку и далее клепать их безо всяких ТЗ, лишь корректируя очередные хотелки заказчика.
ЗЫ: интеграция платежки всегда боль, если для нее нет хорошей либы-обертки
SpiderEkb
22.09.2023 18:21+2И это вы считаете "большим проектом"?
Сравните (АБС- Автоматизированная Банковская Система):
27 тыс. программных объектов
15 тыс. таблиц и индексов базы данных
Более 150 программных комплексов
Занимает более 30 Терабайт дискового пространства
В день изменяется более 1,5 Терабайт информации в БД
За день выполняется более 100 млн. бизнес операций
Одновременно обслуживается более 10 тыс. процессов
За год происходит более 1100 изменений в алгоритмах программ
Подключено более 60 внешних систем, обеспечивающих работу различных бизнес направлений.
Большинство внешних приложений используют систему, как основной источник информации и функциональности
Количество клиентов сейчас - порядка 50млн. С каждым клиентом связано большое количество разных сущностей (счета, клиентские данные, доверенные лица и т.д. и т.п.)
И эта система постоянно развивается и меняется. Изменяются существующие бизнес-процессы, появляются новые. И любое изменение должно быть интегрировано в существующую систему так, что не нарушить ее работу. С учетом того, что бизнес-процессы между собой очень тесно связаны, "задачка со звездочкой".
Вы доказали, что ваш подход работает. Что вам удалось собрать команду и вытроить процесс, где можно работать без ТЗ. Ок. Но это всего лишь частный случай. В других же случаях все будет ровно наоборот - попытка работать без ТЗ просто порушит всю систему.
foxijke Автор
22.09.2023 18:21Так я вроде описал опыт и не пропагандирую этот подход.
А письками мериться у кого больше проект по-моему не слишком правильно
SpiderEkb
22.09.2023 18:21+1Я не меряюсь. Просто привел масштабы для сравнения.
И да, я и в маленьких проектах работал. Ну как маленьких. Так скажем, система мониторинга инженерного оборудования зданий, которая позволяет охватывать большие территории (удаленность объекта от диспетчерской не играет роли).
И там кроме софта еще и железо свое разрабатывали. И заказчику сразу говорилось - по софтовой части (интерфейсы) можно будет что-то в каких-то пределах корректировать, но вся что связано с железом - если мы вложимся в разработку и изготовление железа, а потом вы что-то поменяете в требованиях, то выкупаете все уже изготовленное и делайте с ним что хотите - на стенку повесьте, на помойку отнесите. А мы делаем новое под ваши новые хотелки и потом вы опять его оплачиваете.
И, знаете, очень дисциплинирует заказчика. Когда он понимает, что любой его каприз будет стоить ему дополнительных денег сверх согласованной суммы.
А подход заказчика "сделай то не знаю что, но чтобы мне понравилось" изначально убыточен для разработчика.
foxijke Автор
22.09.2023 18:21Мое мнение что железки и софт сравнивать не правильно
Мы тоже работаем с железками которые сами же заказывали для зарядных станций, и тут совсем другой подход.
SpiderEkb
22.09.2023 18:21А они неотделимы. В той системе суть в том, что на объектах (зданиях) есть некоторое инженерное оборудование. Которое должно мониторится и управляться из диспетчерской. И нужно "железо", которое будет осуществлять сбор информации с оборудования, передачу ее на диспетчерскую (и обратно). И нужен софт, который всю это информацию на диспетчерской собирает и представляет с удобном для человека (диспетчера) виде. Ну и логирование всякое и прочее и прочее.
Сам софт без железа работать не будет. Железо без софта тоже. Так что это, как говорили во времена оные, "аппаратно-программный комплекс". Единый и неделимый.
И в разработке там участвуют и разработчики верхнего уровня и схемотехники (как по цифре, так и по аналогу), разработчики прошивок для контроллеров... И пока они не согласуют между собой все детали (архитектура сети, протоколы обмена, формат адресации устройств и еще кучу вещей), начинать что-то делать бессмысленно - велика вероятность что придется все переделывать (заказывать новые платы, компоненты, все это заново монтировать и т.д. и т.п.).
foxijke Автор
22.09.2023 18:21Это уже специфика проекта когда код и железки неотделимы
У нас все таки проекты про другое
В случае с описанным вами проектом ТЗ в полной мере прям от и до должно быть, тут даже не спорю
SpiderEkb
22.09.2023 18:21+7Лично для меня подход достаточно странный. Вот просто с "моей болотной кочки".
Длительное время работал в обрасти промавтоматизации. Что такое там "без ТЗ". с вероятностью 99% это приведет к тому, что вы потратите деньги на разработку и изготовление "железа" (промконтроллеры, различные модули сопряжения), а потом "концепция поменяется" и все это останется только отправить в помойку и начать все заново. Потерянное время, потерянные деньги. В буквальном смысле слова.
Сейчас банк. Центральные сервера. Где крутится вся бизнес-логика. А он, мягко говоря, не тривиальная. И ее, мягко говоря, слишком много.
На сервере одновременно крутится тысячи, если не десятки тысяч, процессов. И все они так или иначе взаимодействуют друг с другом. Встраивая новый процесс, вы всегда должны думать об интеграции - не скажется ли он отрицательно на всем остальном. В том числе и по потреблению ресурсов - не затормозит ли новый процесс что-то из уже работающего.
Получая требования от заказчика (бизнес-подразделения) вы первым делом выстраиваете архитектуру так, чтобы реализовать их максимально эффективным образом. И если требования начнут меняться по ходу разработки, в скоро убедитесь что изначально выстроенная архитектура летит к чертям и вы своими руками делаете какого-то франкенштейна, неповоротливого и прожорливого. Начинается лютый костылинг результатом которого будет жуткая дендрофекальная конструкция. Или, чтобы этого избежать, вам придется пересмотреть всю архитектуру и начать все с начала. Срывая сроки (а здесь бывает и "нормативка" - жесткий срок к которому процесс должен быть запущен срыв которого чреват санкциями со стороны регулятора). Поэтому практикой выработан жесткий workflow: BRD (бизнес-требования) - архитектурное решение - FSD (ТЗ) - разработка - тестирование -внедрение. Только так и никак иначе. Слишком велика цена ошибок.
Кроме того, ТЗ, это еще и документация по проекту. Нам приходится сопровождать пожизненно все, что мы делаем. Есть некий процесс со своей бизнес-логикой. работает уже 3-5 лет. Писался кем-то когда-то. И приходит вам на доработку - "вот тут поменялись требования регулятора". Или "поменялось законодательство". Или.... Вариантов куча. И чтобы начать доработку вам нужно для начала понять а что там вообще происходит, что и где нужно изменить. И без ТЗ это сделать крайне сложно. Поэтому всегда, по всем проектам хранится архив версий ТЗ. И всегда есть привязка по какой версии ТЗ реализован тот или иной модуль в проекте (в любой поставке есть Release Notes где все ссылки - на задачу в Jira, на ТЗ, на тесты, на коммит в BitBucket...).
И если всю эту "бюрократию" не соблюдать, жизнь станет кратно сложнее.
foxijke Автор
22.09.2023 18:21Выглядит как будто вам все таки нужно не ТЗ, а документация к проекту, которая пишется параллельно разработки
zikkuratvk
22.09.2023 18:21+1Тут про другое когда цена ошибки высока, допустим как в строительстве ее уже нельзя исправить на последующем этапе. Это области которые касаются аппаратно программных платформ, почти вся промышленная разработка и прочее, где нельзя вернуться на предыдущий этап и подкрутить...
Грубо говоря нельзя такие подходы представить в области строительства самолётов :-) точнее они были таковыми, но на начальных этапах, сейчас ждать пока самолёт упадет с пассажирами недопустимо.foxijke Автор
22.09.2023 18:21Согласен, но это другая сфера совсем. Цена ошибки с самолетами уже не упущенная прибыль
SpiderEkb
22.09.2023 18:21В банковской сфере цена ошибки, конечно, не жизни людей, но очень большие цифры. И кроме "упущенной выгоды" есть еще санкции регулятора.
У нас оценка примерно такая:
Час простоя АБС может стоить банку до 24 миллионов рублей прямых финансовых потерь при кратковременной недоступности.
Это не учитывая репутационных потерь, которые могут привести к прекращению банковской деятельности в целом.
SpiderEkb
22.09.2023 18:21+1Нет. ТЗ это во-первых, основа для построения архитектуры и выбора наилучшего алгоритма. Если в процессе бизнес-требования заказчика изменились достаточно сильно, разработчик может вообще отменить задачу и отправить ее на пересогласование (а с учетом того, что у разработчика и аналитика задачи идут потоком, пересогласование означает сдвиг задачи в конец очереди и новое планирование ресурсов, например, на два-три квартала вперед).
Во-вторых - да, ТЗ это документация. И часто бывает так, что изначально аналитик пишет ТЗ "широким мазками" - основные положения, без конкретики реализации. А потом уже дополняет его подробностями конкретной реализации. Правда, такой подход работает только с разработчиками достаточно высокого уровня.
DmitryShm
22.09.2023 18:21+2Для того, чтобы корректно предлагать что-то взамен чего-то, необходимо показать, что отказываемым владели в достаточной мере. Иначе те, кто это читает, могут подумать что ТЗ не нужно.
Написание ТЗ это часть процесса проектирования. В статье с одной стороны не ссылаются на стандарты процессов проектирования, а с другой описывают и предлагают свои активности. Всё это не выглядит профессиональным.
Тем временем сложность никуда не девается. Смысл проектирования и моделирования требований в том, чтобы работать с наиболее рисковыми задачами на раннем этапе. Если задачи лёгкие и можно позволить себе интерфейсом и пользовательскими историями заменить модели - нормально. Но если сложность не будет позволять так делать - коллеги, вероятно, прибегнут к стандартным подходам, если освоят их. Иначе бюджет на переделывание программного кода, когда на программистов будут возложены роли аналитиков, заставит задуматься.Не советую принимать статью, рассказывающую о радостном отказе от ТЗ, всерьёз.
foxijke Автор
22.09.2023 18:21Ваше право
Я лишь описал, как мы работаем. Никакого призыва к действию не было
Наш опыт показал, что так работать можно.SpiderEkb
22.09.2023 18:21+1Вы забываете постоянно добавлять - "в нашем конкретном случае". Вам уже накидали примеров и аргументов что в других случаях это работать не будет. Более того, попытка так работать почти наверняка приведет к крайне нежелательным последствиям.
Предствбте ситуацию когда заказчик вам называет срок и ставит условие что если вы хоть на день в него не уложитесь, то не только ни копейки не получите, но еще и оплачиваете заказчику штраф в размере полной стоимости проекта. Это то, что у нас на называется "нормативка".
Рискнете в таких условиях работать по вашей схеме? Или просто откажетесь?
foxijke Автор
22.09.2023 18:21Да, рискнули и уже не один раз
Два таких проекта реализовано и сейчас в работе есть такие.
И я ничего не забывал добавлять, я описал нашу работу. Моей целью было поделиться что можно и так, а как вы будете работать это выбор вас или вашего руководства.
SpiderEkb
22.09.2023 18:21Ну на самом деле ничего нового вы не открыли. Да, так можно. Но слишком много рисков получить "Франкенштейна" - сначала думали что будет так, по ходу выяснилось что нужно этак, переписывать все времени уже нет, наделали костылей, спихнули заказчику и свалили в даль светлую. А дальше трава не расти...
И с таким, за 30+ лет в разработке сталкивался, увы не раз и не два...
foxijke Автор
22.09.2023 18:21В одной из статей на других источниках я писал про модульный подход к разработке
В этом случае если меняется требование то и модуль полностью выкидывается, а Франкенштейна в этом случае не будет. Заказчик само собой за это платит и как правило это понимает. Не понимает только заказчик который за 3 копейки хочет ракету, но я думаю это точно у всех было )
SpiderEkb
22.09.2023 18:21Простой пример из личного.
Делается некоторая "витрина". Для ее первичного наполнения пишется некоторый модуль с очень жесткими требованиями по производительности (хотя бы потому что оценочно там будет порядка 400млн записей, а запись это не просто что-то выдернутое из другой таблицы, а результат некоторой обработки некоторого объема данных - на то она и витрина).
Изначально были выставлены одни требования. И вроде как все сделали, но тут "концепция поменялась". И стало понятно что базовый алгоритм, дающий хорошую производительность для старых требований, никуда не годится для новых. Т.е. переделать нужно процентов 75-80 написанного... И никакая модульность тут на спасет - это само по себе "модуль" в составе еще более крупной задачи.
foxijke Автор
22.09.2023 18:21Так я про это и написал, модуль который пилили выкинули и на его место вставили новый, при этом другие участки кода не пострадали
И да новый модуль за новую оплату само собой
Tipchak
22.09.2023 18:21+2Очень интересная позиция, но звучит как утопия, если честно))
По Причине 1.
"Зачем пишут ТЗ?"
Тут профит получает не только клиент, но и подрядчик:Это источник правды для команды - без ТЗ у дизайнера может сложиться одно видение, у разработчика бэка - второе, у iOS/Android - третье и четвёртое, а у QA - пятое. ТЗ решает эту проблему - правда в нём.
Как я поняла, у вас в качестве источника правды выступают дизайнеры и проджекты, но странно, что коммуникация внутри команды идёт без них. В таком случае у вас должна быть не только очень сильная команда, но и думающая в одной парадигме)Это страховка подрядчика: если разработка сделана по согласованному ТЗ, но клиент внезапно говорит, что он хотел иначе - всегда можно показать согласованное ТЗ и провести доработку как платный CR, а не как багу.
То что вы пишите далее, что оставляются ссылки на договорённости с клиентом, т.е. "есть доказательства того, о чём мы договорились" - частично решает проблему, но только в рамках договорённостей, которые едва ли охватывают полную функциональность)
По Причине 5.
"Пока ты пишешь ТЗ, у клиента все поменялось внутри"
Возникает ощущение, что аналитик сначала собирает все требования по всему проекту, а потом садится, и не вставая месяц пишет ТЗ на весь проект) Пока аналитик работает над ТЗ по фиче, он плотно взаимодействует по ней с заказчиком, затем согласовывает с ним же и отдаёт в разработку. Если что-то меняется в процессе написания ТЗ - это сразу учитывается в ТЗ, но это редко бывают изменения вселенского масштаба. Тот же переход на другую CRM не делается за один день, и уж конечно о нём заказчик должен предупредить подрядчика заранее
Приходилось сталкиваться с командами, пытающимися работать примерно по такому сценарию - заканчивалось всё добавлением аналитика и ТЗ на проект)
Здорово, что у вас получается, наверное, и правда команда гениев)foxijke Автор
22.09.2023 18:21Все что вы описали происходит у нас внутри, мы просто не пишем огромную мукулатуру а идем итерационно. К сожалению, все в статье передать невозможно, иначе это будет очень нудный пост.
Ссылаясь на ТЗ как к истине как правило клиентом воспринимается в штыки, поэтому наш подход в этом случае более лояльный
И к слов о ТЗ, его нет в том виде в котором его привыкли видеть, но есть описание спринта которое содержит все user story и другое описание
zikkuratvk
22.09.2023 18:21Про команду гениев у меня тоже сложилось мнение. Опять же мы не знаем сколько участников процесса разработки и сколько команд работает. Может быть у нас 3-5 человек и все. И там все это отлично работает, а другой вопрос, как это распространить на скажем 30-50 человек и скорее всего невозможно на 500 человек.
foxijke Автор
22.09.2023 18:21У нас в среднем команда на 15-20 человек
Команды на 500 человек я не встречал ) они как правило бьются на отдельные юниты по 10-20 человек а то еще меньше
beskov
22.09.2023 18:21+2Agile'у в разработке ПО уже 20+ лет, а хипстеры-троечники из региональных студий продолжают переоткрывать для себя его принципы и основания и каждые полгода на Хабре выходит очередное такое откровение от Ерёмы
Откройте сразу Киневин почитать, и правило Коберна «каждому проекту своя методология»
foxijke Автор
22.09.2023 18:21-1простите что городских потревожили. Вы видимо в моменте стали большим и ничего не открывали для себя
aleks-th
22.09.2023 18:21+1А мне больше интересно вот что.
Без ТЗ - заказчик скажет - надо было по другому, вы не выполнили задачу подразумевалось третье - вертайте деньги назад.
Как вы с этот вопрос решите.
Заказчик может пойти в суд и если сможет доказать что имел ввиду другое то деньги вернёт.
С нормально написанным ТЗ где понятно прописан ожидаемый результат, проблем доказать что все сделано как просилось уже не возникнет.
foxijke Автор
22.09.2023 18:21У нас есть соглашение, в котором все описано что человек получает на выходе за спринт
kinall
22.09.2023 18:21+1А чем оно тогда отличается от ТЗ? Или вы назвали ЧТЗ (частичное ТЗ) "соглашением"?
foxijke Автор
22.09.2023 18:21-1В нашем понимании ТЗ это документ в котором описано все со всех сторон вплоть до структуры БД
По крайней мере именно такое мы раньше писали
man55
22.09.2023 18:21+2Понимание у Вас странное. Бизнес не знает слова "БД", ему глубоко наплевать на это и на все остальное "под капотом".
А если Вы раньше "такое писали", а теперь перестали "такое" писать, значит Вы действительно наконец-то поняли, какое ТЗ должно быть - бизнес-функции на понятном клиенте языке. И очевидно, что Вы стали его писать. А статья или про подмену понятий или про настолько простые задачи, что и без ТЗ сойдет.
kinall
22.09.2023 18:21+1Это уже технический проект. Вообще говоря, есть три документа: ТТ, ТЗ и ТП - требования, задание и проект. Разница примерно такая:
ТТ - "мне нужен сайт онлайн-школы";
ТЗ - "сайт он-лайн школы на 5к учеников и 10 преподавателей, с возможностью экспорта в эксель";
ТП - "мы используем Laravel и Mongo DB со следующими доработками...".
ТТ пишет заказчик, ТЗ пишут вместе, ТП пишет исполнитель. Вы от ТП перешли к ТЗ=)
Gar02b
22.09.2023 18:21+1Начав читать Вашу статью, я был сильно против концепции работы без ТЗ.
А прочитав полностью, согласился с Вашей точкой зрения. Грамотно написанные пользовательские истории могут стать отличной заменой классическому ТЗ.
Просто нужно уяснить, что ТЗ и спеки - не одно и то же. Наличие стори не означает отсутствия детальных спецификаций на протоколы взаимодействия и форматы данных.
Я обязательно подумаю над этим на трезвую голову. Может получиться Agile идеальной прожарки.
SpiderEkb
22.09.2023 18:21Тут есть небольшая путаница. Заказчик про ТЗ вообще ни слом ни духом. Его документ - BRD - Business Requirements Document. Вот он согласуется с заказчиком. И заказчик тестирует и принимает продукт на соответствие согласованным бизнес-требованиям.
На основе BRD уже строится архитектурное решение и пишется (специально обученными людьми - аналитиками) FSD - Functional Specifications Document. Это уже внутренний документ команды.
Если в двух словах, то BRD - что будем делать, FSD - как будем делать.
makshantseva_ya
22.09.2023 18:21+2Заголовок статьи "Без ТЗ результат ХЗ. Не думаю" - в статье описывается, какой формат ТЗ используется в компанию.
Уважаемые автор, есть несколько моментов, которые хочется прокомментировать:
Вы никогда не работали с хорошим аналитиком, иначе бы половина описанных проблем у вас не случилось бы;
Открою вам секрет, ТЗ по ГОСТу уже не пишется в большинстве компаний.
foxijke Автор
22.09.2023 18:21-1Все верно, к каком то виде ТЗ все таки есть
Только не в том в котором его обычно ожидают увидеть
Вы первый внимательный читатель )
sshmakov
Почему в два спринта, а не в один? Какой смысл разбивать на два спринта, если результат будет показан только после второго? По-моему, стоит удлинить спринт.
foxijke Автор
Чисто финансовая как правило история, людям надо зп платить
А так как первый спринт как правило про архитектуру и проектирование, то показать реально особо нечего, а кушать хочется ребятам. :)