IT для неайтишников: Срывают сроки, что делать бизнес-заказчику? +3


Срыв сроков и выход за оценки - довольно частая и болезненная проблема бизнеса при взаимодействии с IT-специалистами. Иногда срывы сроков и выходы за оценки начинают приобретать хронический характер и встаёт острый вопрос: «Что же с этим делать?». Давайте рассмотрим, какие действия могут предпринять «неайтишники», чтобы выйти из ситуации. Сразу скажу, что слова: «Просто напишите нормальное ТЗ» - не прозвучат.

Меня зовут Константин Митин. 15 лет занимаюсь коммерческой IT-разработкой, прошёл путь от простого программиста до сооснователя и руководителя группы IT-компаний. Успел побыть тим-лидом, руководителем филиала разработки крупной федеральной IT-компании. Я являюсь одиним из идеологов концепции IT~BP (партнёрство между IT и бизнесом).

Что обычно происходит, когда срываются сроки и превышаются бюджеты? Исполнители начинают говорить о неверной либо неполной постановке задачи, о невозможности произвести точную оценку либо о внезапно вскрывшихся факторах, которые было невозможно учесть заранее. Иногда могут прозвучать слова про частые изменения в постановке задачи и доработки, о которых не было известно на момент оценки.

Несомненно, хорошая постановка задачи очень важна. Если конечному исполнителю не описать, что вы хотите получить в результате, если сделать неправильную либо неполную постановку задачи, то результат получится неудовлетворительным.

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

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

С другой стороны, бизнес-заказчик не является техническим специалистом, поэтому он может сделать лишь бизнес-постановку задачи. Сомнительно требовать от представителя бизнеса «написать нормально ТЗ» (ТЗ — техническое задание). Обычно написать «нормально ТЗ» заказчику помогают бизнес-аналитики, системные-аналитики, руководители проектов. Если бизнес-заказчику предлагается сделать всё собственноручно, то явно что-то идёт не так.

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

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

Прежде давайте всё же посмотрим, а что такое ТЗ на самом деле и зачем оно вообще нужно?

Техническое задание

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

Для интереса берём ГОСТ 19.201-78 «Техническое задание. Требование к содержанию и оформлению», там написано, что техническое задание должно содержать разделы:

  • введение (краткую характеристику области и реализуемого программного обеспечения);

  • основания для разработки (ссылка на документы основания для разработки, нужно для крупных организаций);

  • назначение разработки (для решения каких задач мы это делаем);

  • требования к программе или программному изделию (выполняемые функции, временные характеристики, надёжность, инфраструктура и совместимость);

  • требования к программной документации;

  • технико-экономические показатели (должна быть экономическая целесообразность);

  • стадии и этапы разработки;

  • порядок контроля и приёмки;

  • в техническое задание допускается включать приложения.

В целом, видим, что с 1980-го года ничего кардинально не поменялось. Для описания структуры и формы ТЗ хватает 4-х листов. Различные формы для написания спецификации на программное обеспечение на сегодня общедоступны. Ценность представляет не какая-то стандартная форма, а умение наполнять её содержанием.

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

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

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

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

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

Самое интересное, что для управления процессом реализации погружаться в технические вопросы реализации зачастую нет необходимости.

В своей практике мы в качестве «технического задания» и «спецификации» используем последовательность документов:

  1. Бизнес-требования. Изложение на бумаге от заказчика того, что он хочет получить от системы и особые требования к системе, которые у него есть.

  2. Вижн (видение, представление). Изложение на бумаге того, как мы услышали заказчика и как мы представили себе систему. Обычно это текст на 1-2 листа.

  3. Функциональные требования. Перечисление основных функций в системе на несколько листов. Обычно именно функциональные требования включаются в договор.

  4. Разбивка по этапам реализации. Тоже может включаться в договор.

  5. Макеты приложения и описание пользовательских сценариев.

  6. Если нужно, то архитектурная схема и схема потоков данных между интегрируемыми системами, иногда описание API (Application Programming Interface - формат общения с информационной системой для другой информационной системы).

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

Ставим бизнес-цель

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

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

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

Однако, с какой-то периодичностью для дилеров печатались высококачественные бумажные каталоги, и это стоило больших денег. Решением стала разработка сайта-каталога, на котором сотрудник дилера мог оформить заказ. То есть человек приходил в дилерский центр, просматривал каталог на планшете (либо просто присылал дилеру свой виш-лист), выбирал понравившуюся мебель, сотрудник дилера делал заказ и продолжал сопровождение клиента.

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

Бизнес-цель либо бизнес-задача должны быть критерием сдачи «проекта» самому себе, как заказчику . После того как будет закончена разработка, проведено внедрение и получен опыт эксплуатации, вы должны будете себе честно ответить достигнута ли цель. А так же стоило ли достижение этой цели затраченных усилий.

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

Представляем себе систему

Как говорил Стивен Кови, мысленное творение предшествует физическому творению. Чтобы что-то создать в мире объективной реальности, вы должны это создать в своём воображении. Кроме шуток - нужно. А потом быть способным словами описать тот образ, который вы представили. Желательно письменно, на бумаге, чтобы не возникало ложного впечатления, что вы себе всё представили и уже можете это описывать.

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

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

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

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

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

Передаём образ системы

Вам нужно как-то передать сформированный образ системы команде разработки. Процесс передачи очень важен, в нём есть свои риски, часто первый говорит одно, а второй слышит (и даже читает) другое.

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

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

Конечно, можно переложить на программиста ответственность за решение бизнес-задач, в чём он не компетентен. В ответ он потом вас пошлёт писать правильное ТЗ, в чём будете некомпетентны уже вы. Так и будете ходить по кругу, пока кто-нибудь не сообразит, что дело не в вас двоих, а процесс разработки пора чинить на уровне отдела/департамента/дирекции, а не конкретного программиста.

Допустим, у нас всё работает правильно, и мы общаемся не с программистом, а с бизнес-аналитиком либо руководителем проекта. После рассказа о системе (либо чтения вашего письменного запроса) потребуйте вижн в ответ. То есть принимающая сторона садится и на один лист пишет то, как им представилась система, которую вы описали.

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

По сформированному вижну запросите предварительную оценку. Вилку оценки можно давать навскидку. Помогает упражнение: «Сколько стоят женские сапоги?». На удивление, люди с ходу могут выдавать оценку стоимости женских сапог, не являясь профессиональными «сапожниками» и не являясь сотрудниками магазина женской обуви.

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

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

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

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

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

Проработка требования и разбивка на этапы

Допустим, что вы работаете над проектом, разработка которого занимает несколько календарных месяцев. Значит, вам необходимо проработать требования. Если написать вижн (видение системы) занимает 1-2 часа, предварительная оценка - 0.5-1 часа (это же простая рыночная статистика), то проработка требований - это целый длительный процесс. Точную оценку на проработку требований вы должны получить в момент формирования предварительной оценки системы в целом.

Как уже отмечалось, форм описаний спецификации программного обеспечения (технических заданий) множество. Но крайне желательно, чтобы они включали в себя описание пользовательских сценариев. То есть тех действий, которые должны будут сделать пользователи в системе, чтобы получить требуемый результат.

Вы же должны будете согласовать проработанную постановку задачи? Значит и вы, как нетехнический специалист, должны её понимать. Вряд ли вы до конца поймёте архитектурную схему, схему потоков данных, описание API и прочее. А пользовательские сценарии - поймёте.

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

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

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

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

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

К каждому этапу необходимо прописать критерии сдачи и сценарии, проверяя которые вы, как заказчик, убедитесь, что работа выполнена в полном (оптимистично, конечно) объёме.

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

Длительность этапа не должна превышать нескольких месяцев. Чем длительней срок разработки, тем выше риски, что что-то пойдёт не так. Риски растут не линейно, а по параболе (для простоты).

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

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

Управляем рисками и собираем статистику

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

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

Кроме того, вы сами, когда получите возможность «потестировать» сданные этапы, после приобретения пользовательского опыта, можете решить, что системе нужны доработки. И у вас будет бюджет на реализацию ваших доработок.

Важным показателем является отклонение фактических затрат от запланированных. Чем более часто и масштабней такое отклонение происходит, тем более тревожный это сигнал. Когда у вас на руках есть зафиксированные требования, разбивка по этапам и смета, проводить переговоры с отделом/департаментом/дирекцией разработки куда проще.

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

Подводя итоги

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

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

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

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

Даже более того. На самом деле ровно те же проекты, что в разработке IT-проектов, возникают при постройке частного дома либо работе отделочной бригады. Проблемы возникают одни и те же. Часто возникают.

Ну а ещё, мы наконец-то узнали, что такое на самом деле «ТЗ» и почему просить написать «нормальное ТЗ» бизнес-заказчика - это плохая идея.

Если вы дочитали до конца и написанное было для вас полезным, то спасибо вам.


Полезные материалы по теме:




Комментарии (31):

  1. onets
    /#24883696 / +3

    А что насчет оценки бюджета и сроков на составление ТЗ?))

    • progchip666
      /#24883838 / +3

      Присоединяюсь к вопросу. Это пожалуй самый болезненный вопрос. Как при рамочном ТЗ реалистично оценить сроки и бюджет?

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

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

    • Portnov
      /#24883848 / +2

      Выставляются отдельно.
      В некоторых "особо запущенных" случаях, прежде чем заключить договор на разработку собственно ПО — заключается договор на разработку ТЗ, со своими сроками и бюджетом...

      • progchip666
        /#24884942 / +1

        Я уже начал практировать услугу предварительного аудита проекта за символическую плату в 200 - 400 Евро. Отлично отсеиваются неадекваты, прощупывающие рынок и халявщики.

        Кстати, количество аудитов на самые разные темы уже к десятке приближается и пока не было недовольных, хотя далеко не все итоги можно было считать положительными. Кому тоя просто открыл глаза на реальную трудоёмкость и стоимость проекта, кого то убедил в нежизнеспособности идеи... Люди не заработали денег, но зато и не ввязались в крайне сомнительную авантюру риск в которой потерять всё выше 95 процентов.

        • Gryphon88
          /#24888300

          Как именно аудит проводите? Куда ездите, с кем беседуете? Мне случалось уже после начала проекта ловить за пуговичку в соцсетях предположительного пользователя, чтобы проверить «пользовательские истории».

  2. Zhbert
    /#24883722 / +2

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

    В реальности же (причём не только в ИТ и разработке) обычно срок «ещё вчера», денег в два раза меньше, а ТЗ меняется десяток раз прямо перед дедлайном по принципу «все херня, давай сначала, но денег не дам». Как результат - херачить в режиме «херак-херак-и-в-продакшн» 24/7 под постоянным давлением свыше. Особенный шик, если это все приправлено сверху эффективными менеджерами с KPI, канбанами и прочей новомодной сранью.

    • KongEnGe
      /#24884034 / +1

      Все строго по канве анекдота: "Вам, мышам, нужно стать ёжиками".

  3. ruomserg
    /#24883796 / +5

    Основная проблема подходов "как правильно написать ТЗ" заключается в убеждении, что есть кто-то (человек, группа лиц) - которые уже имеют в голове описание решения задачи, и могут в структурной форме его изложить. Но это только одна из ситуаций, причем довольно редкая.

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

    И тогда составление ТЗ превращается в цирк с конями: сам бизнес никакое ТЗ составить не может, а если составляет ИТ - то бизнес тупо подписывается под всем что принесли (не в силах понять что там написано), а потом начинаются разборки, ближе к концу...

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

    Если вы запускаете ракету (или самолет, или автомобиль) или делаете инсулиновую помпу, или что-то еще в таком духе - ни в коему случае не следуйте выше приведенной рекомендации. У вас в отраслях есть свои стандарты, и им ДЕЙСТВИТЕЛЬНО необходимо соответствовать! Спасибо!

    • progchip666
      /#24883850

      В моей практике происходит именно то, что вы описали. С учётом того, что я работаю не в сфере чистого IT, а разрабатываю электронной оборудование то приходится сталкиваться ситуация в которой на этапе составления ТЗ особо не ориентируешься в задаче. Дают тебе гидравлическую схему какого то оборудования, заранее подобранные датчики и исполнительные механизмы. В результате оказывается что в собранном для тебя опытном образце стоит не то, в алгоритме ошибки, интерфейс не проработан и пошло поехало...

      Главный вопрос - как рассчитать бюджет и время исполнения при работе по аджайлу.

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

      • ruomserg
        /#24883890 / +3

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

        Либо заказчик соглашается платить по принципу Time&Material - либо делить проект на итерации и оплачивать итерации. Второе совсем плохо, потому что кратно увеличивает бюрократию на проекте. В итоге, может оказаться что от проекта где никто не понимает что нужно - но дает фиксированные деньги (и нет 2-4-10x запаса) приходится отказываться. Или делать фактически за свой счет, но с пониманием, что эта задача нужна и другим заказчикам - и можно отбить начальные вложения за счет тиражирования решения на рынке.

        • progchip666
          /#24884002 / +1

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

    • Portnov
      /#24883860 / +3

      1. Оцененный изначально бюджет проекта таким образом проедите примерно к середине второй итерации. Потому что трудоёмкость оценивалась на основании того объёма требований, которые были в самом начале. А итераций меньше трёх-четырёх не бывает. Т.о. заказчик просто переплатит в несколько раз по сравнению с ожидаемой суммой.

      2. С большой вероятностью, "мелочи", которые всплывут примерно на четвёртой итерации, окажутся ключевыми требованиями к системе. "Да, мост хороший и удобный, только нам надо не через Малую Соплю, а через Керченский пролив, а так всё замечательно, немножко поправьте и всё, вам разве не всё равно?".

      А так всё правильно, да...

      ;)

      • ruomserg
        /#24883896 / +1

        Тут уже взаимная ответственность заказчика и исполнителя. Если отрабатывали на итерациях расположение и форму кнопок на панели HMI, а не концепт системы (хотя бы и с кривым интерфейсом) - ну кто виноват-то тогда?! Это уже опыт заказчика и опыт исполнителя должен быть. А без опыта - что угодно запороть можно - проверено и на себе в том числе! :-)

        • progchip666
          /#24884016

          А что делать с заказчиками "без опыта" прикажете? Когда работаешь не с корпорациями, а с мелкими конторами и тем более частными лицами, таких большинство!

          • ruomserg
            /#24884026 / +2

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

            • progchip666
              /#24884046

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

    • progchip666
      /#24884030

      иногда бывает дешевле объяснить программистам бизнес-задачу, а потом выстроить бизнес-процесс заново вокруг хорошего решения

      Совсем маленький вопрос остаётся, как это объяснить заказчику. Когда общаешься напрямую с собственником, ещё куда не шло. Но в ситуации когда не получается выйти на уровень выше технического директора(ещё не худший вариант) попытка рассказать заказчику что мало того, что ему необходимо заплатить за разработку, так и бизнес процессы надо поменять что выходит за рамки его компетенций редко оканчивается удачей.

      • ruomserg
        /#24884052 / +2

        О! Это отдельная тема. Тут нужно или иметь с компанией наработанные отношения, чтобы они тебя по-умолчанию слушали, а не считали что ты с них пришел просто денег срубить... Или надо чтобы у них реально заболело не по-детски. Как, извините, с докторами - которых условно здоровые люди обычно не воспринимают.

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

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

        И это я еще не говорю о взятках и откатах, которыми славен российский корпоративный рынок (причем, как со стороны вендоров дающих, так и со стороны заказчиков вымогающих). :-(

        • progchip666
          /#24884212 / +3

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

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

          Когда я случайно пересёкся с одной комиссией из Роснано и они возмутились почему в стенде по испытанию модулей Пельтье (надо было стабилизировать токи до 60 ампер в широком диапазоне нагрузки) идёт подводка такими толстыми проводами, я попытался объяснить... В ответ получил ценную рекомендацию к следующему разу перестроить установку таким образом, чтобы передавать энергию по блютусу.

          Тут я понял, что пора заканчивать работу с этими ребятами, тем более что они уже и платить перестали...

          Ещё несколько лет эта загадочная контора проработала, привлекая за небольшую плату сотрудников соседних лабораторий для имитации деятельности в момент визита очередной комиссии от Роснано. Потом мои связи с завлабом разорвались, не знаю чем всё это закончилось...

          Вот такие бывают заказчики!!!

          P. S. с тех работаю только с частными конторами...

          • ruomserg
            /#24884226 / +1

            Ну тут ох!.. Если в частном секторе МОГУТ требовать и предлагать взятки - то в (около-) государственном - они смысл жизни видят в попиле и откате. :-(

  4. Nialpe
    /#24884280 / +2

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

    • progchip666
      /#24884544 / +2

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

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

      • Nialpe
        /#24884722 / +1

        У меня так было. Приходит заказчик, а у него от прошлой команды только jar и вперед на декомпиляцию.

        • progchip666
          /#24884892 / +1

          Декомпиляция это круто вообще. И чем закончилось?

          Мы просто код переписали.

          Но в итоге дело совсем не в коде оказалось, а в клубке взаимовлияющих аппаратных и программных проблем.

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

          • Nialpe
            /#24885348 / +1

            Декомпилировал. Некоторые места пришлось пройти разными декомпиляторами, т.к. если не helloworld, то результат декомпиляции не всегда обратный и читаем. Около сотни классов красные в ide. Сел, начал разбираться, через неделю удалось собрать и запустить проект. Еще неделю проверял соответствие требованиям. Кое-что пришлось исправить. А далее уже развитие и доработка под новые требования.

            • progchip666
              /#24886286 / +2

              Снимаю шляпу перед такой работой.

  5. raamid
    /#24884614 / +1

    Тут уже писали про быстрое прототипирование, вставлю тоже свои 5 копеек. Быстрое прототипирование, в котором учтены самые тонкие моменты.

    Например, в моем случае (работа с 3D в Web) - это когда в задаче кроме знакомых элементов используется что-то новое. В этом случае я быстро гуглю, щупаю новую для себя технологию убеждаюсь что она работает и я могу ей управлять. И только после этого начинаю разговор с заказчиком о цене и сроках.

    Это конечно риски для меня, могу просто потратить 1-2 дня на ресерч и никакого контракта не будет, но для меня это того стоит. Во-первых, значительно снижаются риски, что я столкнусь с непреодолимой проблемой в середине проекта и придется все начинать чуть ли не сначала. Во-вторых, я учусь, и это тоже очень важно.

    • progchip666
      /#24884936

      Было в моём последнем проекте и быстрое прототипирование. Запустили экземпляр с упрощённым алгоритмом работы. Даже TFT контроллер запустили.

      Но потом понеслось - вышли панели с графускорителем нового поколения. Мы посчитали что разница незначительная, а она оказалась офигенной с учётом того, что пришлось переходить с псевдографики на графику, а там возникла часть проблем. Среда разработки для нового контроллера оказалось кривой. Примеров практически нет, хотя для старого было дочерта. Немцы отказались поставлять часть комплектухи, пришлось искать замену. Потом другую часть отказались поставлять корейцы. Программист с которым я сотрудничал стал сотрудничать с яндексом и увеличил ценник за свои услуги в два раза. У заказчика пошли проблемы с основным бизенсом по вполне понятным причинам, там все замороченные и получить от них ответы на возникающие проблемы стало почти невозможно... В рамочном задании по графинтерфейсу начали всплывать подводные камни и вразы типа "предусмотреть то-то" иной раз занимали от двух до 4 недель кодинга...

      Словом, всё пошло не так и заложенные в проект риски возросли в несколько раз...

      • raamid
        /#24885268 / +1

        Тут могу только посочувствовать. И у меня подобное было. Когда затраты времени на проект в 3 раза превышают оценку которую ранее дал клиенту. Моя методика не гарантирует что подобное можно избежать, она всего лишь снижает риски.

  6. Adjuster2004
    /#24885648 / +3

    Не так страшны первые 80% проекта, как вторые 80%

  7. Mikhail1972
    /#24886214

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