Всеволод, да 🙂 Хотя я бы сделала оговорку: в сложном проекте исчерпывающее ТЗ с первого раза - тоже редкий зверь. Уточнения и даже изменение решения нормальны.

Для меня граница в другом: если бизнес пока не понимает, что именно ему нужно, это отдельный этап - разобраться, проверить гипотезу, сделать прототип. Но странно выдавать эту неопределённость программисту под видом задачи, а потом итерациями выяснять собственные требования уже на написанном коде.

Получается довольно дорогой способ ответить на вопрос “а чего мы всё-таки хотели?” 🙂

Формулировка требований - это отдельный этап и требует определенной экспертизы. Если требования трудно сформулировать сразу, тогда должен быть какой-то план, как эти требования можно прояснить. И конечно, разработка прототипа может быть частью такого плана. Ну тогда, надо сформулировать требования к прототипу. Программисты отнесутся с пониманием к такому подходу.

Всеволод, да, вот это важное уточнение. Прототип не отменяет постановку задачи - просто меняется сама постановка. Мы уже не говорим “сделайте готовое решение”, а фиксируем, какую гипотезу проверяем, что хотим узнать и по каким признакам поймём результат.

То есть неопределённость вполне можно принести программисту - если честно назвать её исследованием, а не замаскировать под готовое ТЗ

Ничего маскировать не надо. Любая скрытность рождает недоверие и мешает делу.

Павел, с тем, что хороший программист должен мыслить системно, полностью согласна. И на этапе реализации он действительно часто первым ловит дыру в логике: “а что здесь делать, если…?”.

Но я бы всё-таки не делала из этого нормальную архитектуру процесса. До программиста есть аналитики - бизнесовые, системные, - которые как раз и должны превратить набор хотелок в непротиворечивую модель. Разработчик может и должен её проверить реальностью кода, но если ему приходится с нуля собирать ещё и бизнес-логику, мы просто перенесли анализ на самый дорогой этап 🙂

Программист будет рентабельной. Он знает систему лучше, что можно реализовать через готовые решения, в где нужно будет переписать пол проекта.

Да и чем больше людей вовлечено в один процес, тем выше издержки на коммуникацию.

Вообще, идея разделять целостную задачу по нескольким узкоспециализированным специалистам не должно быть нормой. В большинстве случаев такой подход кратно повышает суммарные трудозатраты, на в общем-то простые задачи.

Павел, для небольшой и хорошо очерченной задачи соглашусь: иногда один сильный разработчик действительно дешевле трёх специалистов и пяти созвонов.

Но я бы не переносила это на сложные бизнес-процессы. Там цена коммуникаций конкурирует уже не с нулём, а с ценой поздно обнаруженной ошибки. Если при разработке выясняется, что подразделения по-разному понимают одно правило, данные имеют несколько источников, а исключения никто не определил, экономия на анализе быстро становится довольно дорогой.

Поэтому для меня вопрос не в количестве ролей, а в сложности задачи. Не нужно заводить аналитика ради кнопки. Но и использовать программиста как место, где одновременно выясняют бизнес-логику, согласуют интересы и пишут код, - тоже сомнительная оптимизация.

Дмитрий, новизны - никакой 🙂 В этом, собственно, и проблема. “Сначала договориться, что именно делаем, потом автоматизировать” - банальность уже не первое десятилетие. Но каждый новый проект почему-то умудряется оплачивать её как свежую управленческую находку. Поэтому я скорее не про новизну проблематики, а про цену её хронического игнорирования

Юлия, да. И это тот редкий этап, где отсутствие видимого результата часто и есть работа. Бизнесу кажется, что команда “долго думает”, потому что кнопки ещё нет. А потом выясняется, что именно эти недели сэкономили месяцы переделок. В финансах я бы назвала это очень скучной, но выгодной инвестицией в неслучившийся перерасход 🙂

Тарас, “всего одна кнопка” я бы уже заносила в реестр ранних индикаторов будущего перерасхода 😄 Потому что за ней почти всегда прячется не интерфейс, а договорённость нескольких владельцев процесса. И чем позже выясняется, что у каждого была своя версия того, что именно должна делать эта кнопка, тем дороже она становится. Так что несколько недель на согласование логики иногда выглядят медленно только до первого релиза

Анна, спасибо 🙂 Самое забавное, что самый дорогой этап автоматизации иногда проходит вообще без программиста - в переговорке. Там внезапно выясняется, что у пяти человек пять версий одного и того же “у нас это всегда делается так”

Точно. И хорошо, если это выяснили до момента непосредственной доработки. А то, как правило, уже после. Практически в каждой нетиповой конфигурации вижу как минимум один доработанный функционал, который кто-то когда-то инициировал/реализовал, но он ни разу не использовался. Предварительно не разобрались, как надо и надо ли вообще, но конфигурацию "подпортили"

Да 😄 Иногда самое опасное ТЗ начинается со слов “а можно немножко…”. После “поиграть со шрифтами” внезапно появляется второй бюджет, третий круг согласований и новая версия проекта. Программист вроде бы финал, но “немножко” умеет прекрасно запускать всё заново.