Когда-нибудь даже самый-самый разработчик должен найти в себе силы и мужество отказаться от разработки многостраничного технического задания (ТЗ).
Пришло время понять, что ТЗ это атавизм современного подходя к разработке ПО.Еще десять лет назад программы разрабатывались неспешно по заранее составленному ТЗ. Ну и выходили версии программ раз в год, а то и три. Отдадим должное, это были масштабные релизы.
Но такой подход начал таить в себе большую проблему, когда улучшились инструменты разработки, повысилась скорость работы программистов, стало больше разработчиков. И наконец увеличился спрос на ПО со стороны быстро растущей массы пользователей. Компьютер не просто в каждый дом, компьютер каждому члену семьи. А интернет стал вишенкой на этом торте.
В чем проблема разработки по старым лекалам?
Конкуренция.
Ваша компания тратит время на ТЗ, а потом пишет по нему программу. Вас непременно опередит студент без ТЗ. Он просто опубликует в интернете первую версию программы. Конечно, «сырую» и с ошибками. Если программа полезная, автору напишут об ошибках и покритикуют за отсутствующий функционал. Уверен, автор исправит ошибки и добавит функционал. И у него уже вторая версия программы. А вы все еще пишите первую, причем совершенно не факт, что в направлении потребностей пользователей.Требования бизнеса.
Скорость бизнеса возросла, любой мало-мальский бизнес вышел за рамки своей страны. Появилась потребность в автоматизации рутины и ускорению коммуникаций между сотрудниками, а также с клиентами. Разрабатывать программу целый год перестало быть приемлемым вариантом. «Нужно вчера, максимум — сегодня» — стало лозунгом бизнесмена. Программный продукт состоит из многих компонентом и решает несколько задач. Зачем ждать пока будет разработан весь функционал, если частью его можно пользоваться уже сегодня. Зачем нам ждать целый год всю бухгалтерскую программу, если модуль печати накладных уже готов?Можно найти еще проблем, но я перечислил две основополагающие.
К чему мы приходим?
Мы приходим к возможности (благодаря средствам разработки и тестирования, навыкам и количеству разработчиков) производить продукт не как монолитный дом, а частями. Вы только представьте аналогию: когда строится второй этаж дома, на первом уже живут люди. Фантастика? В ИТ это уже норма. При этом качество постройки возрастает — выявленные на первом этаже ошибки исправляются на втором этаже. К постройке девятого этажа дом становится идеальным для жильцов.К чему я веду такое длинное вступление? Где про ТЗ?
Дело в том, что при описанном выше подходе написать ТЗ на весь проект невозможно. Ни по разумным срокам, ни по охвату функционала программы. К моменту финиша ваш продукт уже устареет.Автор, а ты точно прав?
Посмотрите на график обновления программ. Как часто обновлялись первые версии Микрософт Офис раньше, а как обновляются сейчас? Между Виндовс 95 и 98 три года. А Виндовс 10 обновляется дважды в год. На версии программ уже никто не обращает внимание. Firefox версии 2 и 3 имеет сотни глобальных отличий. А сейчас отличия межу версией 53 и 54 не столь многочисленны. Зато ошибки исправляются быстрее и по отзывам пользователей становится приоритетной разработка именно нужных возможностей программы. Цикл разработки браузеров — новая версия примерно каждые 6 недель.Новые технологии не стоят в стороне. Появился блокчейн (давно появился, но сейчас обрел известность и популярность). Специалистов по нему мало. И опыт и них маленький. Руку набить они еще не успели. Как они могут написать подробное ТЗ, по которому можно разработать продукт? Никак. Это поле для экспериментов, проб и ошибок.
Зачем нужно ТЗ?
Вернемся опять в теорию. Зачем надо ТЗ? Чтобы снизить риск непонимания между заказчиком и исполнителем, между разработчиками, между тестировщиками и так далее. Вопрос денег тоже стоит — оценить стоимость разработки. Но это разовая операция. А снижение риска недопонимания — ключевой фактор, который изо дня в день будет путаться под ногами. Вместо талмуда на 500 страниц ТЗ нужно использовать иные способы (благо их много) снижения недопонимания.Наверное стоит проговорить, что под ТЗ все это время я понимаю многостраничный документ, который досконально подробно и однозначно описывает что и как надо делать. Это оговорка важна, потому-что многие вещи по привычке называют ТЗ, но они им по сути своей не являются.
Работать без ТЗ?!
«Как можно работать без ТЗ?» — воскликнете вы. А я отвечу, за последний месяц мне попалось на глаза для изучения семь ТЗ на разработку сайтов, приложений на смартфоны, разных сервисов. Что я могу сказать хорошего? Ничего.Первая проблема современных ТЗ
Эти ТЗ построены на одном шаблоне, причем очень старом. «Верстка должна корректно отображаться в Internet Explorer версии 5.5 и выше». Черт подери, эта версия существовала 20 лет назад. Я вообще не знаю, где вы найдете Эксплорер младше 8 версии. И вот такая бесполезная дребедень тянется из ТЗ в ТЗ.Вторая проблема подробных ТЗ
Описываются очевидные вещи. «В правом верхнем углу находится крестик для закрытия окна. При клике на нем мышкой окно закрывается».Третья проблема филологических ТЗ
Если первые две проблемы мешают, но хотя бы не вредят, то третья проблема убивает всю разработку и обесценивает ТЗ. «Если пользователь находится в окне модуля А, то ему показывается итоговый остаток на начало дня при условии, что синхронизация по остаткам состоялась не более 24 часов назад». Даю голову на отсечение, что этот кусок кода будет написан неверно даже после пяти итераций. Ну не снижает недопонимание такая фраза из ТЗ. А ведь многие гордятся, что расписали подробно функционал программы.Подвожу итог — ТЗ либо копипаст ради объема, либо описание очевидных вещей, либо сложные словесные конструкции усиливающие недопонимание.
Не вводите клиента в заблуждение
Но все равно многие пишут ТЗ и видят в нем спасение. Ладно клиент, он многого и не должен понимать, ему кажется, что после написания ТЗ он придет к любой команде разработчиков и ему сделают продукт, как там написано. Это совершенно не так. По одному и тому же ТЗ разные команды напишут разные продукты. Но это пол беды. Беда в том, что ТЗ и образ продукта в голове заказчика различается, как сахар и соль. А я видел глаза клиента после демонстрации продукта по утвержденному им ТЗ. По правде говоря, если ТЗ превышает 30 листов, заказчик его не может ни прочитать, ни понять. Приходится нанимать человека-ретранслятора, который прочитает и перескажет заказчику. Ой, я полагаю вы уже представили этот цирк!Елки-палки, не томи, что делать?
Донести до клиента, что с гарантированным (заранее ожидаемым) результатом нельзя сделать даже сайт-визитку из четырех страниц. Как бы подробно мы не описывали, результат совпадет с ожиданиями только через несколько разработок и правок. Итерационного процесса разработки никак не избежать. Ну и смысл тогда все это описывать в детальном ТЗ. Выход есть — нужно составлять не ТЗ, а список пожеланий (хотелок) клиента. Например, хочу, чтобы можно было распечатать карточку товара; хочу, чтобы зеленый цвет был из нашего фирменного стиля и так далее. Это просто список. Чтобы просто не забыть. После этого выбираем несколько наиболее важных вещей из списка и делаем их за определенный период — неделя или две. В момент начала работы над конкретной «хотелкой» выясняем максимально возможные подробности по ее внешнему виду и логике работы. Реализовываем и показываем клиенту. После этого вносим корректировки. И так далее, раз за разом един слона по кусочкам. Если кто-то мне сейчас скажет: «Так это же Аджайл!», я отвечу: «Так что же вы по нему не работаете!»Недостатки, которые достоинства
Недавно я услышал упрек от разработчиков старого поколения, что таким подходом я трачу больше времени на разработку и отвлекаю клиента. Я очень удивился такому упреку, ведь очевидно, что для клиента важна не скорость абстрактной разработки, а то, как быстро он получит новые фишки в своем продукте. Второй момент — если разработчик не готов участвовать в проекте — какими бы методологиями мы бы не пользовались, продукта не получится. Вообще. Человек, который сетует, что тратит на свой продукт несколько часов в день, однозначно не нуждается в этом продукте.Резюме
Я полагаю, что вы поняли логику современной эффективной разработки. Набросали всего, чего хотим. Выбрали первостепенной важности. Разработали. Откорректировали. Опять выбрали, опять разработали, опять откорректировали. Это первая составляющая успешной разработки.Вторая составляющая —инструментарий.. Статический лист Ворда или пэдээф не может передать работу динамичных систем (а именно такие вы и разрабатываете). Поэтому дело за динамичным показом что и как будет работать в продукте. Въедливый читатель воскликнет — так это же и есть ТЗ. Я промолчу и посоветую перечитать статью еще раз.
Комментарии
Отправить комментарий