Comments 21
Многие боятся самой идеи наличия ТЗ, потому что им кажется, что это путь назад, к водопаду и очень медленной разработке, а у нас тут надо очень быстро, по аджайлу, поэтому "на написание ТЗ времени нет". А по факту, если умеючи, то наличие ТЗ сильно экономит время разработки и никак не мешает практиковать аджайл. Ключевое слово "умеючи", разумеется.
ТЗ не передаёт действительных желаний заказчика, а показывает его наивное представление о возможной программе. Поэтому бывает полезным сразу переходить к третьему шагу, не тратя времени на переработку ТЗ.
Ну вот да. То, что Вы говорите - довольно типичное представление, из-за которого на ТЗ "экономят", чем наносят проекту довольно значительный вред.
Я на это смотрю иначе. В процессе разработки приложения всё-равно приходится продумывать все детали реализации, от высокоуровневой архитектуры до мелких низкоуровневых вопросов вроде областей ответственности отдельных модулей/классов/функций. При этом нередко оказывается, что о чём-то подумать забыли, но всплывает этот факт сильно позднее. А, как известно, вносить изменения на ранних этапах (вроде проектирования "на бумаге") значительно дешевле, чем на поздних (в коде, при интеграции или тестировании). Поэтому я считаю разумным разделить ту работу по проектированию, которую в любом случае приходится выполнять (будь то в голове во время набора кода, или при написании ТЗ ещё до набора кода), на два раздельных этапа: написание ТЗ и реализация по этому ТЗ. Этот подход позволяет выявить большинство проблем ещё до появления реального кода, и исправить их намного дешевле.
Один из нюансов - я не пишу ТЗ ради бюрократии, формальностей или переноса ответственности, и не пишу его просто чтобы набрать кучу бессмысленного текста. Мои ТЗ на 90% состоят из того, что действительно необходимо для написания кода, того, о чём всё-равно пришлось бы подумать и принять решение в процессе написания кода, есть ТЗ или его нет.
Другой нюанс - я не пишу слишком поверхностные ТЗ и слишком детальные. Детализация зависит от сложности и неочевидности реализации конкретных функций - для одних я прописываю детальный алгоритм работы, для других просто перечисляю входные и выходные значения. Иными словами в ТЗ должно быть написано достаточно, чтобы любой миддл мог (в большинстве случаев) взять из таск-трекера таску "реализовать такой-то метод API", глянуть в ТЗ описание этого метода, и сделать эту задачу корректно, не требуя дополнительной информации в описании задачи или на митингах.
При таком подходе никаких "лишних" трат времени не возникает. Потому что время потраченное на "набор текста" ТЗ в документ пренебрежимо мало по сравнению с тем временем, которое уходит на продумывание - а это время ушло бы в любом случае, просто у меня оно явно выделено в отдельный этап, а без ТЗ оно было бы замаскировано "написанием кода" (и его многократной переделкой на ходу из-за ошибок в проектировании, допущенных просто потому, что никто не дал себе достаточно времени о них подумать заранее).
На одном из мест работы был следующий подход, но оговорюсь, что ТЗ было на фичу, а не к проекту в целом.
1. я работаю по ТЗ над фичей
2. параллельно, аналитик и менеджер общаются с заказчиком по поводу новой фичи
3. аналитик по итогу п.2 формирует ТЗ и иногдя задает мне технические вопросы по возмоной реализации
4. я заканчиваю с п.1 и получаю ТЗ для новой фичи из п.3
Хороший подход в единой рабочей связке. И работа делается, и новые задачи в пул собираются, проходя технический фильтр (вашу консультацию)! Из видимых минусов, наверное, то, что трудно заложить правильную глобальную архитектуру для будущего масштабирования. А вы сами видите какие-то минусы в таком подходе?
Минус, наверное в том, что заказчик все равно внесет коррективы, когда увидит mvp), но не всегда наблюдалось. Как раз у заказчика развязывались руки, когда хотелки были написаны на коленке.
Про Ваш минус - да, имеет место быть, но можно нивелировать риски в п.3.
Такой подход хорошо живет там, где налажены процессы. В противном случае все скатывается в "уже вчера")
В поликлиниках и крупных автосервисах есть персонал который работает с клиентами, а есть люди, которые с клиентами не работают. Аналогично в разработке - есть аналитики, есть программисты, есть менеджмент. В некоторых компаниях какие-то роли объединены, и программист общается с заказчиком, выясняет его потребности и составляет ТЗ. В других компаниях программист может вообще не иметь доступа к заказчику, а работать только по задачам, спускаемым сверху - что бизнес с аналитиками придумает, то наш программист и будет делать. В аналогии с больницей он подобен сотруднику хим. лаборатории - ему приносят материал, он делает анализы, а ставить диагнозы и назначать лечение не его задачи. Разумеется это не снимает с него ответственности в случае, например, если на анализ А принесли материал Б - об этом надо сообщать ответственным лицам, а не писать отсебятину, в надежде что "и так сойдет", но и звонить персонально клиенту и договаривать с ним на забор материала - скорее всего оверкил (зависит от процессов).
Мне кажется, в данной статье автор во многом пытается доказать кодерам, что им надо быть аналитиками. Ну и немного говорит про ответственность и работу на результат. Ответственность и работа на результат - это все верно, а вот для аналитики все же часто нанимают отдельных специалистов, потому что это отдельная сфера деятельности и чтобы стать хорошим аналитиком, нужно этому учится. Хотя бы того же Вигерса прочитать для начала. Для общего развития будет в любом случае полезно, но нужно ли это всем...
Даже приятно увидеть себя на скринах.
А теперь давайте вспомним, что такое современная разработка.
Программист очень часто не видит ни тз, ни чего либо еще кроме задач, нарезанных лидом и аналитиком. Его могут перебрасывать между проектами, у него нет контекста общения с заказчиком. Он безусловно должен озвучивать проблемы, но не имея контекста не всегда может делать это корректно. В данном случае очень похоже на желание заменить "дорогих" лидов и архитекторов, на "дешевых" разработчиков.
Текст написан для лидов\аналитиков\небольшой части сеньеров, но никак не для большинства разработчиков.
Возможно то, что Вы описали, корректно если под "программистом" имеется в виду частный случай "раб на галерах". А если говорить о другом частном случае - продуктовом стартапе а не галере - тогда у программистов обычно есть и доступ к заказчику, и между проектами их не перекидывают, так что в этом случае описанное в статье вполне валидно.
Вы смешали всё в одну кучу. Я работаю над одним и тем же продуктом уже 10 лет. Ни о каких "продуктовых стартапах" никогда не слышал. При этом между мной и клиентом два слоя других людей. Зачем мне прямой доступ к клиенту? Разве что баг на месте "пощупать".
Прямой доступ к клиенту нужен всегда - потому что всегда есть нюансы предметной области, которые желательно уточнить до написания кода. Потому что если их не уточнить - они всё-равно всплывут позднее, при тестировании или уже в эксплуатации, но тогда их учесть и всё пофиксить обойдётся намного дороже.
Другое дело, что "клиент" в этом контексте - это не обязательно исходный заказчик продукта, который деньги платит. Это может быть Ваш тимлид, архитект, бизнес-аналитик или тех.дир - кто угодно, кто обладает необходимой информацией, и у кого Вы всегда можете её уточнить. А вот если и они не знают, тогда либо они должны уточнить таки непосредственно у заказчика, либо это должны сделать Вы сами - но у обоих подходов есть свои плюсы и минусы.
Плюсы того, что с заказчиком пообщаетесь Вы - не будет потенциального испорченного телефона и задержек коммуникации, особенно когда начинаются уточняющие вопросы. Минусы - полученное Вами знание может дальше Вас не уйти, а было бы полезно, если бы вышеупомянутый архитект-аналитик-etc. тоже был в курсе этой информации. Ну и другой частый минус - не у каждого программиста достаточно хорошо прокачаны софт-скиллы и знание языка, на котором разговаривает заказчик, чтобы прямая коммуникация была продуктивной.
Плюсы того, что с заказчиком будет общаться архитект-аналитик-etc. в том, что у него кругозор намного шире чем у линейного разработчика озабоченного тонкостями реализации конкретной фичи, так что начав с озвученной разработчиком проблемы архитект-аналитик-etc. может развернуть этот вопрос более глобально, и нередко это может привести даже к значительной переработке архитектуры - и это опять же хорошо, потому что это всё-равно бы случилось, но так это случилось раньше, и поэтому обойдётся дешевле.
В идеальном мире, кто бы ни общался с заказчиком, и даже если никто не общался (на вопрос разработчика смог самостоятельно ответить архитект-аналитик-etc.), необходимо полученную информацию внести в то же ТЗ - где её смогут увидеть все остальные. Просто по принципу раз вопрос возник - значит текущая документация недостаточно подробная, и нуждается в уточнении.
Плюсы того, что с заказчиком пообщаетесь Вы - не будет потенциального испорченного телефона и задержек коммуникации
В моём случае, наоборот. Специально обученные люди переведут слова клиента на с языка юзера на язык программиста.
А если считать заказчиком того, кто мне задачу ставит - то это мой генеральный, и, конечно, с ним у меня прямая связь.
Это валидно, если это мини компания или фриланс. Где программист выполняет несколько ролей. В компании с выстроенными процессами, это разные люди. Никто не спорит, что в идеале, они все были взаимозаменяемые, и т.д
Но вот например пара человек из моей команда:
- Крутой спец, которого на пушечный выстрел нельзя подпускать к заказчику, или получим кучу бомбежа, "они все идиоты".
- Крутой спец, который пошлет заказчика нахер.
- Неплохой разраб с жутким синдромом самозванца, а следовательно с проблемами, когда надо отстоять свою точку зрения.
Да со всеми тремя идет работа, и эти проблемы исправляются. Но они не хотят, и не смогут выполнять работу менеджера\аналитика\лида. И они прекрасно вписываются в свое место.
про ТЗ в разрезе ИС - на заре карьеры участвовала в крупном проекте, в котором год был заложен на написание только функциональных требований, потом их пересматривали не раз уже в процессе внедрения. ИС работает как часики до сих пор.
На нынешнем месте работы в более мелком предприятии ТЗ не делают, все на коленке, как левая нога решила - переделок огромное море, кривущие системы, вечно какие-то логические тупики и костыли по устранению оных. По сути меня одну здесь не устраивает отсутствие четкой зафиксированной постановки/документации/ответственности, а вот моих коллег (без какого-либо опыта работы с ТЗ) ничего не смущает, они не видят проблемы (а на самом деле все проще - я все сделал правильно, пользователь сам дурак, не знает чего хочет, не может мне объяснить правильными словами, я никому ничего не должен, мне за интуицию не платят и тд и тп из статьи выше).
в общем - да, ТЗ это ресурсозатратно, но в плане организации конструктивной работы вполне обосновано. Можно рассмотреть как показатель зрелости специалиста (личности?).
это, конечно, все вне системы четкой иерархии ИТ сотрудников в организации, она априори должна быть )
Год на ТЗ - это как раз страшная память со времён водопада, из-за которой многие всё ещё боятся самой идеи "сначала написать ТЗ". Потому что, и правда, тратить год на ТЗ в наши дни ни у кого возможности нет. Да и смысла в этом, если честно, тоже нет - за год слишком много всего изменится, от требований бизнеса и состояния рынка до актуальных технологий. Надо учиться писать ТЗ так, чтобы это не было трудозатратно, и не занимало неприемлемо много времени. Условно говоря, ТЗ на небольшой микросервис надо выдавать за неделю-полторы, и потом реализовывать этот микросервис примерно столько же времени.
год на ТЗ - оптимальное время для вписания всего производственного цикла (от планирования до отгрузки) очень крупного предприятия в одну недешевую информационную систему, нет там столько изменений на единицу времени ) да и цена вероятной ошибки выходит высокой...
естественно, не всем сферам это актуально, у каждой своя специфика и нюансы, ни в одном месте не призываю к единому стандарту ) поэтому упомянула, что речь идет о ИС...
Лемма: все люди совершают ошибки, причём довольно регулярно, и чем сложнее задача - тем больше ошибок.
Дано: ТЗ год писали люди.
Ergo: в ТЗ будет полно ошибок.
Перефразирую: микросервисы придумали именно для того, чтобы не писать ТЗ год.
Общее время на описание ТЗ для очень крупного предприятия в одну ИС действительно может быть и годом. Но нельзя это делать в один заход и одним куском. Нужно сначала описать архитектуру верхнего уровня (а то и её часть) одним небольшим ТЗ, потом сделать ТЗ на пару небольших модулей этой архитектуры, и дальше можно садить разработчиков писать код этой пары модулей, параллельно с тем, что архитекты продолжают писать ТЗ на другие модули. Ну т.е. этап декомпозиции можно и нужно применять не только к задачам в таск-трекере, но и к общей задаче написания ТЗ на ИС предприятия. И в обоих случаях выдавать нужно законченные куски работы, чтобы через месяц после начала работ уже пара модулей была реализована и протестирована (а, в идеале, и выкачена на площадку, если эти модули реализовывать как отдельные микросервисы), хотя до завершения ТЗ в целом ещё около года.
С того времени, как стал требовать ТЗ перед началом разработки сайтов - у меня нет клиентов на создание сайтов. И черт с ними, надоело переделывать самим за собой "чтобы посмотреть", потому что всегда получал ТЗ вида - "ты этим занимаешься, тебе лучше знать". А потом вдруг "лучше знать" начинает клиент, когда задача уже выполнена. Удобно, ТЗ то нету.
Уже в конец обленились и не могут скинуть несколько сайтов конкурентов. В лес таких заказчиков, пусть с собой разбираются.
Представляю, что творится в командах разработки, ну нафиг такую работу.
Я в этой ситуации всегда писал ТЗ сам, и давал заказчику на аппрув перед началом разработки. Ожидать что заказчик будет в состоянии подготовить ТЗ самостоятельно - это наивно и не работает на практике. Ожидать что он поймёт ТЗ даже не на 100%, а хотя бы на 50% - тоже наивно. Тем не менее, от той части ТЗ, которую заказчик смог понять и заапрувить или скорректировать - всегда есть достаточно значительная польза, чтобы этим имело смысл заниматься.
И, да, аппрув ТЗ от заказчика не значит, что у его требования не изменятся когда он увидит первый прототип. Изменятся. Это нормально. Просто изменившиеся требования надо внести в ТЗ и снова отдать на аппрув. (Брать за них дополнительные деньги или нет - это уже зависит от нескольких других факторов и в данном контексте не так важно, но если брать - то это обычно проще сделать, если заказчик участвует в процессе внесения изменений в ТЗ и понимает, из-за чего увеличилась стоимость проекта.)
Да, всё именно так, как написал тот челик: бизнес сам виноват, если сказал "да, делайте вот так", а когда ему сделали "вот так" сказал"я вообще не этого хотел". В плане ТЗ никто никому ничего не должен. У бизнеса есть свои люди, которые квалифицированны на создании ТЗ, а программист квалифицирован на его выполнении. У действий должна быть инструкция, пусть даже и высокоуровневая, а если её нет, то и не нужно удивляться, почему что то сделано не так (сам разработчик плохо понял "как надо").
Конечно, эмоциональный интеллект важен. Однако он важен именно для того, чтобы уметь работать с людьми, которые не умеют работать с тобой, и не готовы подстраиваться под тебя. Не "благодаря", а "вопреки". И я честно не увидел каких-бы то ни было неверных суждений от "типичного программиста". Попытку же его перефразировать можно описать как "хотел обосрать, но забыл снять штаны" – хотел выставить позицию насчёт обязательного ТЗ глупой, но в итоге не смог это аргументировать сильнее шуток "никто никому ничего не должен"/"моя хата с краю краю ничего не знаю" и примера с врачом. Реальных аргументов почему программист обязан "по чуйке" определять что от него хотят, а заказчик, если это не оборонка, может забить на описание что хочет получить на выходе (и в следствии на выходе может получить не совсем то, что хотел) нет. Только начало статьи, а уже вымораживает
Спасибо за статью. Со всем согласна, и с комментариями тоже.
Отношение к ТЗ в современных ИТ-проектах