Комментарии 95
Я брал в два спринта задачи, которые мог показать и сдать.
Почему в два спринта, а не в один? Какой смысл разбивать на два спринта, если результат будет показан только после второго? По-моему, стоит удлинить спринт.
ну хоть бы опрос дали, конечно тз важен, в лендинги может и не нужен или где можно наговнякать, а так да заказчик всегда барин и если можно с ним договорится что лучше сделать "а" чем "б" но это не отменяет того факта что сделается адекватный тз с пожеланиями клиента и который заапрувили разработчики, иначе у вас рано или поздно вылезут какието конфликты или по срокам или по оплате, а эти "наши супер дизйнеры, синьеры и етц держат нос по ветру и так знают как им делать" это вобще печаль в нормальной разработке
Это наш опыт о котором мы решили рассказать не через 1 или 2 проекта, а когда сделали уже с 2 десятка
Изговнякать можно что угодно
Но когда цель выпустить продукт в срок и нормального качества, то проще все решать с клиентами по факту
Лендинги мы не делаем, мы занимаемся только большими проектами. Так что если в команде хорошо выстроены процессы и есть толковые люди, то будет успех, а если все в носу ковыряют, то и с тз можно знатно обкакаться.
В том-то и соль, это ваш опыт. Часто причину путают со следствием. Причина успеха не способ организации команды, а сама команда. Как следствие, команда эффективней быстрее вот так (без ТЗ).
А теперь представьте абсолютно рандомную команду. Т.е. вам известен количественный состав и уровень (честный). Будет ли всё работать также?
Отсюда очень сильный перекос менеджмента в сторону процессов. При чём зачастую на фоне важности этих процессов люди растворяются и превращаются в безликий ресурс.
Когда в команде: толковые ребята, они друг с другом на одной волне, всем комфортно по основным направлениям, то подойдёт любой процесс, который не будет им мешать. Замечу. Не помогать, -- не мешать.
Намек на то, что требование ТЗ должно настораживать заказчика, ведь возможно он попал на рандомную команду безликого ресурса, а не на толковых ребят работающих на одной волне? )
Какой же намёк? Вы рассказываете, что с ТЗ плохо, а без ТЗ хорошо. А дело вовсе не в ТЗ.
Ещё неизвестно, что вы вкладываете в понятие ТЗ. Это должен быть талмуд на 1000 страниц, описывающий в деталях взаимодействие фронтенд-бекенд? Или ТЗ всё же, это ожидания заказчика? И что плохого или сложного, чтобы договориться на берегу. Что заказчик ждёт, за что платит, когда он это получит, и будет ли результат соответствовать его ожиданиям?
Может вы от ТЗ никуда и не уходили, просто тот набор артефактов, с которым вы оперируете почему-то не дотягивает до вашего понимания "ТЗ"?
В общем, всё очень странно. Если команда находится внутри компании-заказчика, работать мелкими итерациями по аджайлу удобно и комфортно. Если же это аутсорс, то за что платить деньги? Если нет зафиксированных ожиданий в виде ТЗ, за что платить? Как фишка ляжет? Это настолько офигенная аутсорс команда, что всё на полном доверии, и оплачивается просто время, а не получаемый результат? :)
Вопросов больше чем ответов. Договорные отношения как выглядят? Мы не знаем что мы для вас сделаем, мы не знаем чего мы хотим, но это вот столько стоит, потому что "ребятам надо что-то кушать" :)
Про намеки писал Вам не я )
Ваше право иметь другую точку зрения. То что работает у нас возможно не сработает в других командах. Все люди разные, поэтому каждая точка зрения в том числе ваша имеет место быть.
О, извините :) Не обратил внимания, что комментарий не авторский.
Но отвечу вам. Мне кажется писать кому-то о том, что он имеет право на другую точку зрения несколько странно. Как будто мне великодушно позволено мыслить иначе. Спасибо огромное! Прям камень с души. А то вдруг нельзя, и на меня заявят в органы :)
Но вопрос остаётся открытым. Либо вы под ТЗ понимаете что-то уровня ГОСТ-документации со всеми болтиками-винтиками, вплоть до количества строк кода и сколько байт будут занимать бинарники и контент. Либо это просто выглядит очень странно. При чём тут вообще точка зрения? Договорные отношения в государстве не должны быть субъективными.
А то, я приду к вам, заплачу. И скажу. По моей точке зрения, вы сделали не то, не так, стоит оно не столько, и вообще мне всё не нравится. Верните деньги пожалуйста.
Что будем делать? У нас ведь нет никакого ТЗ, ребята просто что-то там делали, и выдали какой-то там результат. Мне такой результат вообще не понравился. Вы потратили моё время, также нужно ещё возместить за потраченное время.
Просто интересно, как это у вас работает?
У нас есть описание в доп соглашении чтт заказчик получает на выходе
Для этого не обязательно писать ТЗ, и да у нас понимание ТЗ именно ближе к ГОСТУ так как есть проекты близкие к госам
Язвить кстати не обязательно про точки зрения, я лишь хотел сказать, что если у кого то не работает, как у нас, то это не значит что вообще ни у кого не заработает
Ещё неизвестно, что вы вкладываете в понятие ТЗ. Это должен быть талмуд на 1000 страниц, описывающий в деталях взаимодействие фронтенд-бекенд? Или ТЗ всё же, это ожидания заказчика?
Я уже писал ниже (или выше?) - ожидания заказчика - это BRD. ТЗ - FSD. Первое есть согласованный с заказчиком документ (в принципе, с ним можно и в суд если возникнут разногласия на этапе сдачи-приемки-оплаты), второе - чисто внутренняя документация команды в любой удобной ей форме.
Лично я даже "непроектные", технические задачи не делаю без предварительного планирования - понимания как это будет выглядеть, как использоваться, каковы основные сценарии, граничные условия и т.п. Пока всего этого нет, нет понимания что именно нужно делать и как. Потому что переделывать все 10 раз просто потому что изначально чего-то не учел у меня просто времени нет - все техническое-непроектное делается в "свободное от работы время". Которого катастрофически мало.
У меня был кейс с маркетплейсом: клиент хотел площадку с безопасной сделкой. Начинаю, делаю, когда дохожу до неё, оказывается, пеймент флоу, по которому заказчик хотел работать, не реализован ни у одной платежной системы.
Получается, вы не анализировали ТЗ перед тем как начали что-то делать?
Ага, выучили слово ТЗ и давай по нему работать, а то что сначала пакет документации надо разработать в виде UX стратегии, информационной архитектуры, блюпринта и как следствие пак ТЗ под конкретные составояющие, это нет — долго и дорого. Я от ТЗ отказался в угоду документации, графической и видео, да сижу по таймлайну отмечаю где для дизов инфа, где для тех директоров.
Я забодался после вас переделывать. Не конкретно вас, а вообще. После таких умельцев, которые без ТЗ код фигачят.
Хех... а вы пробовали без ТЗ автоматизировать хоть, сколько нибудь сложный бизнес процесс. На самом деле тз нужно заказчику, чтоб понять, что он хочет. На этапе проработки задания, как правило задача аналитика утрясти процесс не только для разработчиков, но и для клиентов.
Для примера:
Как звучит процесс для руководителя бизнеса. Мы получаем прибыль с продажи.
Для отдела логистики. Мы отправляем грузы по складам и заказчикам.
Для отдела скажем продаж. Мы выполняем планы по продажам.
И так далее в зависимости от того, куда вы придёте у всех будет разное виденье процессов и скорее всего ни один человек в компании не будет знать, как в реальности продается товар. Все видят свою маленькую часть, ньансов смежников могут не знать, а часто они вообще не представляют, что творится у его же сотрудника за соседним столом.
И вот вы такие пришли хорошие и сделали как вам сказал скажем начальник отдела продаж... а потом выяснилось, что интересы других вы не учли вообще... и да вы быстро сделали молодцы :-) но потом 10 раз переделали. Я просто сейчас наблюдаю, как менеджеры бьются за сокращение проработки заданий на разработку, но экономя 10% времени, они часто тратят +100% времени разработчика. За то да шороху наводят знатного...
И ещё чем меньше по объему задача, тем она как правило понятнее и прогнозируемая по времени исполнения... но чтоб эту задачу декомпозировать на много мелких... нужно понимание общей задачи.
Опять же судя по всему вы решаете достаточно типовые для вас задачи, в таких случаях может быть и прокатывает.
Отлично описали, только все эти этапы мы проходим с каждым руководителем, поэтому имеем довольно полную картину. Задачи типовыми у нас не назовешь, мы разработали уже почти с десяток онлайн-школ и одна из них входит в топ-2 России в сфере школьного образования.
Кол-во персонала сократилось, учитывая что многие процессы были автоматизированы
В штате сейчас у них больше 1тыс человек.
И кстати, мы там ничего ни разу не переделали. :)
Вы гении :-) либо чего то очень сильно не договариваете. Если бы я не участвовал и не был свидетелем нескольких сот проектов я бы может и поверил :-) не бывает такого, чтоб не переделывали...
При таких подходах заказчик ищет правильный путь путем экспериментов, то есть он сам не знает конечный результат. А значит вы приходите на сессию скажем с начальником отдела, он вам говорит одно, потом при проверке выясняется, что нужно было другое, это по ТЗ то регулярно происходит. А в таких процессах разработки просто могут сказать, мы тут подумали и решили, что надо все по другому. Делаем вот так. Я даже могу сказать почему, потому что заказчик не скован конечными требования, и полет фантазии обычно не ограничен, плюс не заставляет его выяснять на первых этапах, как работает тот или иной процесс. Это с одной стороны не плохо, позволяет быстро сделать mvp и проверить гипотезу с другой стороны часто ведёт к растягиванию разработки и ухудшает качество кода.
А как в этом помогает ТЗ? По факту, оно будет согласовываться невероятно долго или, как обычно, часть руководителей передаст ответственность на кого-то другого. В момент приемки все это всплывёт в виде несоответствия с реальными бизнес-процессами и исполнитель будет вынужден отстаивать свою позицию на основе подписанных документов. Ситуация может легко измениться и со сменой одного из руководителей. При итеративный разработке остаётся больше степеней свободы, чтобы это учесть и подстроиться.
Собственно для этого и нужны аналитики, чтоб собирать пазлы.
Давайте по другому рассмотрим вопрос на примере дома. Можно ли дом построить без проекта? Частный жилой дом, да наверное можно. Многоквартирный - невозможно.
Давайте смотреть на разработку ПО. Можно ли написать по которое реализует бизнес процесс не понимая как он работает? Да можно... но вы будете всегда возвращаться на несколько шагов назад, чтоб что-то подкрутить, что то исправить, что то доработать, так как тут мы несли что в этом справочнике нужны такие данные, тут нам надо получить данные из других систем потому, что мы не знали, что они нужны вообще, мы о такой системе даже не знали. На выходе может получится Франкенштейн. Работать будет, возможно, но не факт, что хорошо.
Теперь представим что мы делаем какую нибудь систему которая объединяет много бизнес процессов:-) вот тут мы сталкиваемся с тем, что цели ещё более размыты, а иногда при итерационной разработке даже толком и не известны. И вам надо паралельно разработать 5 таких процессов. Знаете какая боль будет? А ведь там менеджеры проекта могут даже не задать вопрос зачем это мы делаем. Я видел как до 50% конечного продукта после этого выкидывалось, хотя тут надо сказать и видел как продукты разработанные по ТЗ выкидывались. Но тут суть не в этом в результате мы можем получить какую то кашу, которая неизвестно как работает и неизвестно отвечает ли настоящим требованиям заказчика.
Не совсем корректное сравнение. Дом это как правило законченный проект, который должен прийти к логическому завершению, иначе это называется долгострой, что в нашей стране запрещено )
Проекты, особенно большие, это как правило процесс бесконечный. Компания растет, приходят новые люди, выстраиваются новые процессы и тд.
От каши спасает как правило документация, в которой все описано.
Тут мы рискуем уйти в спор о терминологии. На мой взгляд, итерационная разработка никак не мешает проектированию общей архитектуры системы, а также появлению документации. Но ТЗ по водопаду будет существенно отличаться от проекта в итерационной разработке.
Пример с домом не совсем отражает ситуацию даже не этапе строительства. Если взять хорошую команду, которая делала многократно похожие проекты и доводила их до продакшена, затем набрать общую структуру проекта и декомпозировать все строительство на понятные команде блоки, то локально специалисты смогут принять все необходимые решения о материалах, инструментах и методах. В итоге, дом будет построен. Но, в отличии от дома, программный продукт гораздо более живой и модифицируемый, с одной стороны, а также более абстрактный с другой. Поэтому и методы работы должны различаться, с учётом их особенностей.
Я взял многоквартирник в пример. Потому, что там без проекта полного невозможно построить, что-то причем полного. Вы не сможете без него ничего рассчитать и у вас очень ярко проявится факторы: я думал, я так всегда делал, да вы ничего не понимаете. И вам не поможет, то что у вас мега опытные рабочие и прорабы... :-) так как весь процесс не будет помещаться в одну голову. Ну и собственно на стройке идёт именно итеррационная разработка, по полному проекту. Сами рабочие не знают на кой эта работа нужна и как этот узел который они сейчас заливают отразится на всем здании.
Из моего опыта все же работают комбинированные подходы, когда нам ясны процессы, но не проработаны до деталей, они и становятся нашим первоначальным ТЗ. Потом когда мы уже опускаемся на уровень реализации действий, мы уже делаем итерации иногда настолько мелкие, что задача может для разработчика составлять 1-3 дня. Таким образом мы можем прогнозировать, что она завершится в обозримые сроки, он ее поймет и даже если постановщик накосячил цена ощибки будет минимальная. Когда мы нарезаем задачи даже в 5 дней, уже возникают проблемы с прогнозами реализации задачи.
мы стараемся бить задачи на 1-2 дня для разработчиков
Для клиентов все выглядит по другому. И внутри компании у нас недельные спринты начинающиеся со вторника, так как если разраб не успевает закрыть за неделю задачи, то у него всегда есть выходные чтобы нагнать.
Не хотел бы я у вас работать :-)
Да вас никто и не зовет =)
У одного крупного производителя форточек из города Редмонд задачи разбиваются до размера в 4 часа. Я, например, своим джунам всегда говорю: два часа тупишь без продвижения - зови старшего. Если задача на неделю, то можно и пару дней тупить.
Так что рабочий процесс у всех разный, размер задачи зависит от многих факторов.
Менеджер ошибся в оценке сроков?)
Очень жаль ваших менеджеров если им приходится делать оценки, у нас это происходит совместно с разработчиком где он под это подписывается
Это я вам как собственник говорю ))
Так мир не идеален, такое может и бывает в 1 из 50 задач, но это не носит массовый характер
Вы же это преподносите так будто у нас люди 24/7 пашут, а это в корне не так
У нас штат 50+ человек, уволилось по собственному за 6 лет человек 5 всего
По-моему это о чем-то да говорит
Программисты хорошо делают у вас оценку или обычно вынуждены перерабатывать? На мой практике, программисты очень часто недооценивают затраты, забывая включить какой-то ресерч, транзакционные издержки и слепые зоны. Также у большинства разработчиков есть стремление показать, что они смогут решить задачу более оперативно и ответственно, чем обычно выходит, и это также приводит к недооценке.
Как вы с этим справляетесь на практике? Или, как собственник, вы закрываете на это глаза, оставляя ответственность самим исполнителям?
Те кто работает 3+ месяцев как правило попадают и делают даже раньше срока
Переработка является исключением и случается крайне редко
Что подразумевается под переработкой?)
Если программист не успевает выполнить задачу днем, в рабочее время, то имеет полное право заниматься ею в выходные, если это идейный программист, если он горит желанием развиваться и решать проблемы.
Причины "неуспевания" в рабочее время: мало ли что могло случиться - сервер навернулся внезапно, интернет отключился, сеть барахлит, народу в офисе много (если опен спейс), дети бесятся (если на удаленке и есть дети), кошка с ума сходит и мешает работать (если на удаленке и нет детей, но есть кошка)...
ИМХО, я не считаю такие моменты переработками. Даже когда работаю в выходные по задаче/проекту, я все равно развиваюсь. Ведь почему я не смог решить ее в рабочее время? Потому что не хватает компетенций.
В рабочее время у меня его свободного не так много, могут быть ограничения на интернет-ресурсы в целях кибербезопасности, зато на выходных я могу свободно обратиться к интернету и прочитать/посмотреть/найти нужную мне информацию, и может быть даже к ПН закончить какой-то этап.
Поэтому, что считать переработкой?
Угу особенно учитывая, то что обычно закрытие задачи зависит минимум от двух людей. От постановщике и исполнителя. То есть если постановщик недоработал, то исполнитель пожертвовал своими выходными :-)
То есть то что исполнитель не справился не рассматривается ?)
Да и у нас в компании это носит исключительный характер а не массовый
то что исполнитель не справился не рассматривается ?
Странно звучит, учитывая выше ваши громкие заявления:
Каждый член команды важен, никто не передает недоделанную или сделанную плохо работу дальше по цепочке. Все без исключения понимают, какие задачи бизнеса они выполняют своей работой
Такие заявления подразумевают найм исполнителей уровня сильно выше среднего, чтобы обладать навыками аналитика, менеджера и разработчика\дизайнера в одном лице. В таком случае исполнитель может не справиться с задачей в срок только если ему не дали исчерпывающей информации или она была некорректная (не берем в расчет факторы самого исполнителя: заболел\забухал\запрокрастинировал, для high-grade спецов такое недопустимо). А раз такое случается, то это явный косяк управления. Либо же вы лукавите и нанимаете зеленых юнцов с горящими глазами, но малым опытом, которые не могут на лету придумывать реализацию лишь по одной бизнес-хотелке в силу отсутствия опыта в таких задачах.
Ваш кликбейтный заголовок работает лишь для очень ограниченного скоупа работ, в ограниченном домене бизнеса и с очень крутой командой. Без этого проекты будут обречены на провал. К примеру я работаю на бэке в "кровавом энтерпрайзе" и у нас без ТЗ результат не то что не ХЗ, а его вообще не может быть. У нас заинтересованных (и не очень) сторон владельцев систем, которых затрагивает очередная модификация нашей системы может быть цать штук. И со всеми надо договориться, согласовать документы и сроки. У вас ТЗ составляет до 25% от объема проекта, а у нас вся первичная документация до 50% всех трудозатрат проекта, реализация лишь порядка 20%, тестирование еще 20%, остальное это нецелевые потери ТДЗ. У вас можно без ТЗ придумать и реализовать на ходу новый бизнес-процесс по продаже товара из корзины, выбору нового партнера доставки, проведению чекаута и его финальной оплаты через новую платежку. Оформление страниц, шрифты, цвета и надписи кнопок не столь важны. Потому как вам известен финальный пункт - проведение платежа и известны промежуточные этапы. У нас же в рамках одной интеграции с партнером может быть один-пять-цать бизнес-процессов. И часто бывает что бизнес-процессы похожи в коде, но различаются по сути. К примеру есть два разных канала приема сообщений от партнера, два бизнес-процесса помимо многих прочих, но внутри нашей системы они выглядят в коде одинаково, одинаково обрабатываются и складываются в одну и ту же таблицу БД. И надо добавить функционал: при ответе партнеру на его сообщение, добавлять еще и вложения скачанные из двух разных смежных систем в зависимости от канал приема (сканы подписанных бух доков). И ответ надо отправлять через тот же канал, откуда пришел изначальный запрос. Вопрос в какой бизнес процесс это добавлять если в коде он един? И на каком этапе обработки? Без ТЗ все это выяснить читая лишь один код крайне затруднительно (а подчас невозможно). И это лишь самое простое, а в нашей области такое сплошь и рядом. Это результат n-лет эволюции функционала систем, понятно что с нуля так никто писать не будет. И когда мне приходит очередная задача на разработку в бизнес-процессе который я ранее не знал, я ищу все ТЗ в нашей knowledge-base касающиеся сабжа и читаю описания что, куда и зачем. Только так можно понять и реализовать то, что требуется. Да у нас тоже бывают факапы, когда приходится работать на выходных. Но это исключительная ситуация, случается 1<= в год и полностью оплачивается т.к. руководство понимает, что это их прокол. Ситуаций когда разработчик "не успел" и вынужден работать на выходных за свой счет не должно быть и в хороших фирмах не практикуется.
Именно, факапы случаются и выходные оплачиваются если это действительно не факап по причине самого спеца
За свой счет в выходные работают только те кто по своей же вине не успел сделать это в будни, разве это не справедливо?
И еще вы сравниваете продуктовую и заказную разработку
Тут есть разница
Судя по вашему описанию у вас продукт который существует уже не первый год
С помощью ТЗ удобнее ориентироваться что делать и как делать при разработке и не надо каждый раз дергать заказчика с вопросами "а тут как сделать, а тут так подойдет?". Взял ТЗ и написал код, делов то )
Есть ощущение что у вас одеты розовые очки через которые вы смотрите на этот мир )
Если бы все так было просто…
Забавно, но читателям вашей статьи точно так же может показаться, что автор в розовых очках.
Вы работаете в своей нише, где исполнителям ясны их задачи, а заказчиков устраивает процесс и результат. Вы молодцы, что отбросили ненужные формальности. Но вокруг полно других примеров, народ в комментах пишет об этом.
Возможно, просто наша практика показала что отклонений от тз слишком много и в нем нет смысла
отклонений от тз слишком много
Так ТЗ это не закон сохранения энергии, его же можно и подкорректировать.
ЗЫ Интересные у вас заказчики. С одной стороны забюрократизированные до крайностей, и без нескольких месяцев согласований ТЗ все равно не будет. С другой стороны, просто берут и принимают результат работы, без никаких формальностей.
Похоже на манифест "Пиши код б@#&!". И есть ощущение, что это хорошо работает на приложениях для самокатов и бизнес-софта мелких фирмочек, а сломается на чём-то сложном, вроде системы учёта в масштабе завода.
За 2023 год уже запущено 5 онлайн-школ с разными бизнес процессами. В одной из них 20к+ пользователей
Все довольно хорошо работает.
На счет самокатов, я кстати с вами не соглашусь, там не все так просто. Попробуйте поработать с китайскими протоколами на основе которых работают платы. Я думаю вы поменяете свое мнение.
Ряд проектов онлайн школ (не айтишной тематики) которые я видел (знакомые просили распарсить и слить видео-курсы для личного архива), не отличаются оригинальностью и в целом сильно похожи. Думаю после 5 сданных проектов можно хорошо набить руку и далее клепать их безо всяких ТЗ, лишь корректируя очередные хотелки заказчика.
ЗЫ: интеграция платежки всегда боль, если для нее нет хорошей либы-обертки
И это вы считаете "большим проектом"?
Сравните (АБС- Автоматизированная Банковская Система):
27 тыс. программных объектов
15 тыс. таблиц и индексов базы данных
Более 150 программных комплексов
Занимает более 30 Терабайт дискового пространства
В день изменяется более 1,5 Терабайт информации в БД
За день выполняется более 100 млн. бизнес операций
Одновременно обслуживается более 10 тыс. процессов
За год происходит более 1100 изменений в алгоритмах программ
Подключено более 60 внешних систем, обеспечивающих работу различных бизнес направлений.
Большинство внешних приложений используют систему, как основной источник информации и функциональности
Количество клиентов сейчас - порядка 50млн. С каждым клиентом связано большое количество разных сущностей (счета, клиентские данные, доверенные лица и т.д. и т.п.)
И эта система постоянно развивается и меняется. Изменяются существующие бизнес-процессы, появляются новые. И любое изменение должно быть интегрировано в существующую систему так, что не нарушить ее работу. С учетом того, что бизнес-процессы между собой очень тесно связаны, "задачка со звездочкой".
Вы доказали, что ваш подход работает. Что вам удалось собрать команду и вытроить процесс, где можно работать без ТЗ. Ок. Но это всего лишь частный случай. В других же случаях все будет ровно наоборот - попытка работать без ТЗ просто порушит всю систему.
Так я вроде описал опыт и не пропагандирую этот подход.
А письками мериться у кого больше проект по-моему не слишком правильно
Я не меряюсь. Просто привел масштабы для сравнения.
И да, я и в маленьких проектах работал. Ну как маленьких. Так скажем, система мониторинга инженерного оборудования зданий, которая позволяет охватывать большие территории (удаленность объекта от диспетчерской не играет роли).
И там кроме софта еще и железо свое разрабатывали. И заказчику сразу говорилось - по софтовой части (интерфейсы) можно будет что-то в каких-то пределах корректировать, но вся что связано с железом - если мы вложимся в разработку и изготовление железа, а потом вы что-то поменяете в требованиях, то выкупаете все уже изготовленное и делайте с ним что хотите - на стенку повесьте, на помойку отнесите. А мы делаем новое под ваши новые хотелки и потом вы опять его оплачиваете.
И, знаете, очень дисциплинирует заказчика. Когда он понимает, что любой его каприз будет стоить ему дополнительных денег сверх согласованной суммы.
А подход заказчика "сделай то не знаю что, но чтобы мне понравилось" изначально убыточен для разработчика.
Мое мнение что железки и софт сравнивать не правильно
Мы тоже работаем с железками которые сами же заказывали для зарядных станций, и тут совсем другой подход.
А они неотделимы. В той системе суть в том, что на объектах (зданиях) есть некоторое инженерное оборудование. Которое должно мониторится и управляться из диспетчерской. И нужно "железо", которое будет осуществлять сбор информации с оборудования, передачу ее на диспетчерскую (и обратно). И нужен софт, который всю это информацию на диспетчерской собирает и представляет с удобном для человека (диспетчера) виде. Ну и логирование всякое и прочее и прочее.
Сам софт без железа работать не будет. Железо без софта тоже. Так что это, как говорили во времена оные, "аппаратно-программный комплекс". Единый и неделимый.
И в разработке там участвуют и разработчики верхнего уровня и схемотехники (как по цифре, так и по аналогу), разработчики прошивок для контроллеров... И пока они не согласуют между собой все детали (архитектура сети, протоколы обмена, формат адресации устройств и еще кучу вещей), начинать что-то делать бессмысленно - велика вероятность что придется все переделывать (заказывать новые платы, компоненты, все это заново монтировать и т.д. и т.п.).
Лично для меня подход достаточно странный. Вот просто с "моей болотной кочки".
Длительное время работал в обрасти промавтоматизации. Что такое там "без ТЗ". с вероятностью 99% это приведет к тому, что вы потратите деньги на разработку и изготовление "железа" (промконтроллеры, различные модули сопряжения), а потом "концепция поменяется" и все это останется только отправить в помойку и начать все заново. Потерянное время, потерянные деньги. В буквальном смысле слова.
Сейчас банк. Центральные сервера. Где крутится вся бизнес-логика. А он, мягко говоря, не тривиальная. И ее, мягко говоря, слишком много.
На сервере одновременно крутится тысячи, если не десятки тысяч, процессов. И все они так или иначе взаимодействуют друг с другом. Встраивая новый процесс, вы всегда должны думать об интеграции - не скажется ли он отрицательно на всем остальном. В том числе и по потреблению ресурсов - не затормозит ли новый процесс что-то из уже работающего.
Получая требования от заказчика (бизнес-подразделения) вы первым делом выстраиваете архитектуру так, чтобы реализовать их максимально эффективным образом. И если требования начнут меняться по ходу разработки, в скоро убедитесь что изначально выстроенная архитектура летит к чертям и вы своими руками делаете какого-то франкенштейна, неповоротливого и прожорливого. Начинается лютый костылинг результатом которого будет жуткая дендрофекальная конструкция. Или, чтобы этого избежать, вам придется пересмотреть всю архитектуру и начать все с начала. Срывая сроки (а здесь бывает и "нормативка" - жесткий срок к которому процесс должен быть запущен срыв которого чреват санкциями со стороны регулятора). Поэтому практикой выработан жесткий workflow: BRD (бизнес-требования) - архитектурное решение - FSD (ТЗ) - разработка - тестирование -внедрение. Только так и никак иначе. Слишком велика цена ошибок.
Кроме того, ТЗ, это еще и документация по проекту. Нам приходится сопровождать пожизненно все, что мы делаем. Есть некий процесс со своей бизнес-логикой. работает уже 3-5 лет. Писался кем-то когда-то. И приходит вам на доработку - "вот тут поменялись требования регулятора". Или "поменялось законодательство". Или.... Вариантов куча. И чтобы начать доработку вам нужно для начала понять а что там вообще происходит, что и где нужно изменить. И без ТЗ это сделать крайне сложно. Поэтому всегда, по всем проектам хранится архив версий ТЗ. И всегда есть привязка по какой версии ТЗ реализован тот или иной модуль в проекте (в любой поставке есть Release Notes где все ссылки - на задачу в Jira, на ТЗ, на тесты, на коммит в BitBucket...).
И если всю эту "бюрократию" не соблюдать, жизнь станет кратно сложнее.
Выглядит как будто вам все таки нужно не ТЗ, а документация к проекту, которая пишется параллельно разработки
Тут про другое когда цена ошибки высока, допустим как в строительстве ее уже нельзя исправить на последующем этапе. Это области которые касаются аппаратно программных платформ, почти вся промышленная разработка и прочее, где нельзя вернуться на предыдущий этап и подкрутить...
Грубо говоря нельзя такие подходы представить в области строительства самолётов :-) точнее они были таковыми, но на начальных этапах, сейчас ждать пока самолёт упадет с пассажирами недопустимо.
Согласен, но это другая сфера совсем. Цена ошибки с самолетами уже не упущенная прибыль
В банковской сфере цена ошибки, конечно, не жизни людей, но очень большие цифры. И кроме "упущенной выгоды" есть еще санкции регулятора.
У нас оценка примерно такая:
Час простоя АБС может стоить банку до 24 миллионов рублей прямых финансовых потерь при кратковременной недоступности.
Это не учитывая репутационных потерь, которые могут привести к прекращению банковской деятельности в целом.
Нет. ТЗ это во-первых, основа для построения архитектуры и выбора наилучшего алгоритма. Если в процессе бизнес-требования заказчика изменились достаточно сильно, разработчик может вообще отменить задачу и отправить ее на пересогласование (а с учетом того, что у разработчика и аналитика задачи идут потоком, пересогласование означает сдвиг задачи в конец очереди и новое планирование ресурсов, например, на два-три квартала вперед).
Во-вторых - да, ТЗ это документация. И часто бывает так, что изначально аналитик пишет ТЗ "широким мазками" - основные положения, без конкретики реализации. А потом уже дополняет его подробностями конкретной реализации. Правда, такой подход работает только с разработчиками достаточно высокого уровня.
У меня тоже финтех. Подписываюсь под каждым словом. Все так.
Ваше право
Я лишь описал, как мы работаем. Никакого призыва к действию не было
Наш опыт показал, что так работать можно.
Вы забываете постоянно добавлять - "в нашем конкретном случае". Вам уже накидали примеров и аргументов что в других случаях это работать не будет. Более того, попытка так работать почти наверняка приведет к крайне нежелательным последствиям.
Предствбте ситуацию когда заказчик вам называет срок и ставит условие что если вы хоть на день в него не уложитесь, то не только ни копейки не получите, но еще и оплачиваете заказчику штраф в размере полной стоимости проекта. Это то, что у нас на называется "нормативка".
Рискнете в таких условиях работать по вашей схеме? Или просто откажетесь?
Да, рискнули и уже не один раз
Два таких проекта реализовано и сейчас в работе есть такие.
И я ничего не забывал добавлять, я описал нашу работу. Моей целью было поделиться что можно и так, а как вы будете работать это выбор вас или вашего руководства.
Ну на самом деле ничего нового вы не открыли. Да, так можно. Но слишком много рисков получить "Франкенштейна" - сначала думали что будет так, по ходу выяснилось что нужно этак, переписывать все времени уже нет, наделали костылей, спихнули заказчику и свалили в даль светлую. А дальше трава не расти...
И с таким, за 30+ лет в разработке сталкивался, увы не раз и не два...
В одной из статей на других источниках я писал про модульный подход к разработке
В этом случае если меняется требование то и модуль полностью выкидывается, а Франкенштейна в этом случае не будет. Заказчик само собой за это платит и как правило это понимает. Не понимает только заказчик который за 3 копейки хочет ракету, но я думаю это точно у всех было )
Простой пример из личного.
Делается некоторая "витрина". Для ее первичного наполнения пишется некоторый модуль с очень жесткими требованиями по производительности (хотя бы потому что оценочно там будет порядка 400млн записей, а запись это не просто что-то выдернутое из другой таблицы, а результат некоторой обработки некоторого объема данных - на то она и витрина).
Изначально были выставлены одни требования. И вроде как все сделали, но тут "концепция поменялась". И стало понятно что базовый алгоритм, дающий хорошую производительность для старых требований, никуда не годится для новых. Т.е. переделать нужно процентов 75-80 написанного... И никакая модульность тут на спасет - это само по себе "модуль" в составе еще более крупной задачи.
Очень интересная позиция, но звучит как утопия, если честно))
По Причине 1.
"Зачем пишут ТЗ?"
Тут профит получает не только клиент, но и подрядчик:
Это источник правды для команды - без ТЗ у дизайнера может сложиться одно видение, у разработчика бэка - второе, у iOS/Android - третье и четвёртое, а у QA - пятое. ТЗ решает эту проблему - правда в нём.
Как я поняла, у вас в качестве источника правды выступают дизайнеры и проджекты, но странно, что коммуникация внутри команды идёт без них. В таком случае у вас должна быть не только очень сильная команда, но и думающая в одной парадигме)Это страховка подрядчика: если разработка сделана по согласованному ТЗ, но клиент внезапно говорит, что он хотел иначе - всегда можно показать согласованное ТЗ и провести доработку как платный CR, а не как багу.
То что вы пишите далее, что оставляются ссылки на договорённости с клиентом, т.е. "есть доказательства того, о чём мы договорились" - частично решает проблему, но только в рамках договорённостей, которые едва ли охватывают полную функциональность)
По Причине 5.
"Пока ты пишешь ТЗ, у клиента все поменялось внутри"
Возникает ощущение, что аналитик сначала собирает все требования по всему проекту, а потом садится, и не вставая месяц пишет ТЗ на весь проект) Пока аналитик работает над ТЗ по фиче, он плотно взаимодействует по ней с заказчиком, затем согласовывает с ним же и отдаёт в разработку. Если что-то меняется в процессе написания ТЗ - это сразу учитывается в ТЗ, но это редко бывают изменения вселенского масштаба. Тот же переход на другую CRM не делается за один день, и уж конечно о нём заказчик должен предупредить подрядчика заранее
Приходилось сталкиваться с командами, пытающимися работать примерно по такому сценарию - заканчивалось всё добавлением аналитика и ТЗ на проект)
Здорово, что у вас получается, наверное, и правда команда гениев)
Все что вы описали происходит у нас внутри, мы просто не пишем огромную мукулатуру а идем итерационно. К сожалению, все в статье передать невозможно, иначе это будет очень нудный пост.
Ссылаясь на ТЗ как к истине как правило клиентом воспринимается в штыки, поэтому наш подход в этом случае более лояльный
И к слов о ТЗ, его нет в том виде в котором его привыкли видеть, но есть описание спринта которое содержит все user story и другое описание
Про команду гениев у меня тоже сложилось мнение. Опять же мы не знаем сколько участников процесса разработки и сколько команд работает. Может быть у нас 3-5 человек и все. И там все это отлично работает, а другой вопрос, как это распространить на скажем 30-50 человек и скорее всего невозможно на 500 человек.
Agile'у в разработке ПО уже 20+ лет, а хипстеры-троечники из региональных студий продолжают переоткрывать для себя его принципы и основания и каждые полгода на Хабре выходит очередное такое откровение от Ерёмы
Откройте сразу Киневин почитать, и правило Коберна «каждому проекту своя методология»
про_программиста_и_качели.жпг
А мне больше интересно вот что.
Без ТЗ - заказчик скажет - надо было по другому, вы не выполнили задачу подразумевалось третье - вертайте деньги назад.
Как вы с этот вопрос решите.
Заказчик может пойти в суд и если сможет доказать что имел ввиду другое то деньги вернёт.
С нормально написанным ТЗ где понятно прописан ожидаемый результат, проблем доказать что все сделано как просилось уже не возникнет.
У нас есть соглашение, в котором все описано что человек получает на выходе за спринт
А чем оно тогда отличается от ТЗ? Или вы назвали ЧТЗ (частичное ТЗ) "соглашением"?
В нашем понимании ТЗ это документ в котором описано все со всех сторон вплоть до структуры БД
По крайней мере именно такое мы раньше писали
Понимание у Вас странное. Бизнес не знает слова "БД", ему глубоко наплевать на это и на все остальное "под капотом".
А если Вы раньше "такое писали", а теперь перестали "такое" писать, значит Вы действительно наконец-то поняли, какое ТЗ должно быть - бизнес-функции на понятном клиенте языке. И очевидно, что Вы стали его писать. А статья или про подмену понятий или про настолько простые задачи, что и без ТЗ сойдет.
Это уже технический проект. Вообще говоря, есть три документа: ТТ, ТЗ и ТП - требования, задание и проект. Разница примерно такая:
ТТ - "мне нужен сайт онлайн-школы";
ТЗ - "сайт он-лайн школы на 5к учеников и 10 преподавателей, с возможностью экспорта в эксель";
ТП - "мы используем Laravel и Mongo DB со следующими доработками...".
ТТ пишет заказчик, ТЗ пишут вместе, ТП пишет исполнитель. Вы от ТП перешли к ТЗ=)
Тогда всё-таки ТЗ есть, а уж в какой оно форме - третий вопрос.
Начав читать Вашу статью, я был сильно против концепции работы без ТЗ.
А прочитав полностью, согласился с Вашей точкой зрения. Грамотно написанные пользовательские истории могут стать отличной заменой классическому ТЗ.
Просто нужно уяснить, что ТЗ и спеки - не одно и то же. Наличие стори не означает отсутствия детальных спецификаций на протоколы взаимодействия и форматы данных.
Я обязательно подумаю над этим на трезвую голову. Может получиться Agile идеальной прожарки.
Тут есть небольшая путаница. Заказчик про ТЗ вообще ни слом ни духом. Его документ - BRD - Business Requirements Document. Вот он согласуется с заказчиком. И заказчик тестирует и принимает продукт на соответствие согласованным бизнес-требованиям.
На основе BRD уже строится архитектурное решение и пишется (специально обученными людьми - аналитиками) FSD - Functional Specifications Document. Это уже внутренний документ команды.
Если в двух словах, то BRD - что будем делать, FSD - как будем делать.
Заголовок статьи "Без ТЗ результат ХЗ. Не думаю" - в статье описывается, какой формат ТЗ используется в компанию.
Уважаемые автор, есть несколько моментов, которые хочется прокомментировать:
Вы никогда не работали с хорошим аналитиком, иначе бы половина описанных проблем у вас не случилось бы;
Открою вам секрет, ТЗ по ГОСТу уже не пишется в большинстве компаний.
Публикации
Без ТЗ результат ХЗ? Не думаю