Всем привет.

Прошу поделиться опытом.
Как максимально точно оценить трудозатраты при разработке по ТЗ? Речь о человеко-часах.
Да, вопрос очень общий, задачи бывают разные. Наверняка, всё приходит с опытом, но если до некоторого момента не приходилось самому заниматься оценкой? Всегда косячу и выдаю какой-то бред, либо слишком много, либо мало, такое чувство, что абсолютно отсутствует чувство времени.
По моему мнению, в основу должны входить:
1. Само время оценки
2. Время на разбор программного кода
2.5. (в сложных случаях) время на составление модели (нового механизма, обособлено или в рамках существующего проекте)
3. Время на коддинг.
4. Время на тестирование/отладку.
5. Риски, связанные с какими-либо другими обстоятельствами, которые могут возникнуть косвенно или извне на любом этапе, и увеличить общее время разработки.
Рабочая ли это схема? Но как приплести сюда цифры?
На что стоит опираться при расчете? Как это делаете вы?

Как видите, вопросов больше, чем ответов.

Спасибо за конструктивный фидбэк.

(27) это все очень приблизительно все равно
бывало были отчеты, на которые неделя-две уходило

(19) Спасибо за реальный пример. (22) правильно написал, тип, если ТЗ, то ТЗ, об остальном - давай разговаривать тогда. Но всё бывает, и часто, люди не знают, что они просят, фантик с точки зрения юзера - перепил четверти конфы для разраба.

(19) заказчик просто не в курсе был по доработкам?
в процессе было сказано что это неучтенные изменения это доп деньги, будем делать?

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

(30) Нет конечно - не в курсе..
Я же часы озвучивал - типа ТЗ это 4 часа. А вот то что я неделю под его хотелки допиливал - так видимо это я даун корявый, в 1с не шарю.

(30) а если соскакиваешь с получения законченного решения в середине процесса, то вообще уходишь без денег. Время свое потратил и ничего не заработал.

С барыгами обычно так и бывает. Им нужно делать самые простые штучки и строго за фиксированную таксу. Иначе вообще денег не получишь.

(32) ну сам посуди (со стороны), реально же раскручиваешь на деньги выходит.

(0) ИМХО (жизненно подтвержденый работой на фикси вкупе с франчами). То что франчи выставляют по часам вначале - в любом случае будет уплочено вдвое больше. Так-же как и сроки сдачи "под ключ" (еще ни разу не сдавали, все допиливалось собственными силами) умножаем надва.
В своем "микромире" вы можете оценивать хоть в часах, хоть в попугаях. Клиенту важна конечная дата и сумма. Все остальное (время работы, ставка, количество персон) ему по барабану.

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

(32) Твоя ошибка конечно же в том, что ты не обозначил повышение озвученной ранее стоимости работ

(36) "конечная дата и сумма" об этом можно говорить только при наличии у клиента конкретных желаний.

(38) Стоимость работ не менялась. Как было озвучена сумма за работы описанные в ТЗ, так и было сделано.
То что овер - за это я и попросил денежку

(39) А что Вы имеешь ввиду? Обычно, как раз есть только клиент и конкретное желание.
А вот со всем остальным приходится самому.. После твоих сроков и суммы, вы либо договаривайтесь, либо не оч.
Я про что, согласен с (36), но чтобы эти сроки и суммы ставить, нужно на что-то опираться, и в рамках отсутствия опыта оценки, для меня, по крайней мере, это на практике оказывается сложной подзадачей, а по факту - это сама суть всей работы. Время и деньги.

(40) Ну это ты уже придираешься :) Читай тогда как "Выполнял какие-то доп. работы без озвучивания из стоимости, т.е. "на удачу""

+40 У клиент шиномаонтаж .Я оперировал - вот типа сами представьте, приезжает к вам клиент переобуться.. Ему говорят это 1,5 круб. Он ок.
Потом просит: стекла помойте.. шины почерните. И вообще мне колеса не нравятся - поменяйте их местами.
Ессно за это ему выставят счет.

Я свой прайс озвучивал - столько то руб в час.

(39) Вы часто встречали ситуацию, когда задача между заказчиком и исполнителем ставится четко и понятно обоим сторонам?
ИМХО такое возможно как минимум через пол-года совместной работы на предприятии, что-бы исполнитель знал чего хотят или захотят пользователи. Зачастую, ответственные за постановку задач, работники предприятия озвучивают основную суть, подразумевая "это вы сами должны знать, ибо это прописные истины", не вдаваясь в подробности. В итоге, потратив часа 4 по регламенту, вы сделаете отчет, НО не в строку (как думал бухгалтер) а в столбик. Соответственно вы потратите еще пару часов что-бы это исправить.
Так вот и вопрос: как быть с доп. двумя часами? Повесить на не правильную постановку (это доказуемо только при видеосъемке при постановке задачи) или отработать бесплатно.

(43) Обратный пример. К тебе приехал колиент и заказал поменять колеса. Ты ему выставил 1,5 тыр. ОК. Разошлись.
Ты ставишь колеса.
Приходит клиент и говорит: Чувак, а почему колеса неотбалансированы, я думал в 1,5 тыр входит балансировка. Кароче, или балансируешь, или я поехал без оплаты, т.к. работы не выполнены полностью.

(44) Нет, по этому никогда не называю конечную дату и сумму. Любой каприз за ваши деньги

(0) Оценка должна быть интервальная: "от и до".

Разбиваешь задачу по пунктам и каждый пункт оцениваешь. На каждый пункт нужно выставить три оценки: пессимистичная оценка, реалистичная и оптимистическая. Т.е., к примеру, нужно разработать отчет.  Отчет несложный, можно уложиться в 4 часа (минимум) - это оптимистическая оценка. Но есть какие-то моменты, которые тебе непонятны. На эти моменты накидываешь время на "разруливание". Допустим на это хватит 2 час. Т.е. пессимистическая оценка - 6 часов. Реалистичная может быть как "по середине" (3 часа), так и сдвинута в "+" или "-".  Тут тоже на твой профессиональный взгляд (лучше время увеличить, скорей всего ты не все учтешь). Мы не будем пессимистами и выставим реальную оценку в 4 часа.

Считаем расчетное время: (Оп + Ор*2 + Оо) / 4,
где Оп - оценка пессимистическая,
Ор - оценка реалстичная,
Оо - оценка оптимиистичная.

В итоге получаем (6 + 4*2 + 4) / 4 = 4,5.
И так по всем пунктам.

В итоге, у тебя будет время "от и до" и некоторое расчетное время, которое более менее отражает реальную картину.

Теперь что касается тестирования.  Тут можно просто накинуть сверху 30% (если сложный проект, то 40%) от полученного времени.

Вот и вся арифметика.

(46) Вот! Это правильный подход. В договоре с клиентом ты должен указать ориентировочную стоимость проекта и сроки, с обязательным пунктом увеличения стоимости и сроков, предусмотреными доп. соглашениями. И каждый "чих" фиксировать.

(6) > сколько занимает такая адаптация? Месяц, 3, 6, год?

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

(45) Плохой пример.
Прайс - это описание услуги и стоимость. Если клиент не ознакомился - то это проблемы клиента.

(45) Снимаешь колеса и отдаешь назад в том же виде как принимал.

(51) И клиент возвращает потраченное на него время :)

(50) Нет, это прекрасный пример. Ты, как специалист, не сказал, что балансировка не входит в стоимость, а она необходима. Это хорошо, если водитель об этом знает, а если причиной ДТП/крупной поломки, будет неотбалансированное колесо? Кому претензии будут предъявлять?
Сдается мне, что ты программист из серии "поменял 18% на 20% в номенклатуре, как просили и все. остальное ваши проблемы. Хотя просили сделать в номенклатуре 20% что-бы считалось правильно.

(53) "Кому претензии будут предъявлять? "
Апостолу Петру?

(54) Ну это в лучшем случае, а то затраты на "восстановление" будут неподъемны:)

(47) Спасибо! Это интересный вариант, я попробую прикинуть на практике.

(47) А ТЗ бесплатное что ли?
А по факту чем короче проект - тем больше шанс ошибиться в оценке.
За сколько бы я сделал * 2 как правило очень близко к истине. Сделаешь быстрее - и клиенту хорошо и тебе.
Сделаешь медленнее - всем плохо.

(57) А так - чем бесплатнее тз - тем больше гуляют цифры в оценке

(53) "Ты, как специалист, не сказал, что балансировка не входит в стоимость, а она необходима"
Че-то я не помню такой обязанности.

(53) "балансировка не входит в стоимость, а она необходима"
Это уже не по теме 1с - но балансировка не обязательна.

(49) Это справедливо. Спасибо. Можно 1 раз сделать конвертацию какую-нибудь простенькую, а через месяц получить более сложную и тут опыт первой непонятно вообще приведет ли к чему то. Ведь с одной стороны, с областью ты знаком уже, с другой - много нового ещё придется открывать для себя.

(53) Как это не странно - следить за состоянием своего ТС - это твоя обязанность, а не работников центра.
Виноват будешь ты.
То же самое и с 18-20. Сказал поменять, тебе и поменяют, а за результат - это шоловная боль других людей, я например не могу сказать все места, где это вылезет сразу.

(62) Как минимум ставя задачу, считается хорошим тоном описывать проверочный кейс.

(60) Даже сход-развал по большому счету обязателен при замене резины, ибо та резина которую ставишь может иметь другое пятно контакта (съедена наполовину с наружной стороны, например)

(64) Не путай теплое с пушистым.
Желательно и обязательно разные вещи.

(62) если произойдет авария то виновником будешь ты. Потом в порядке регресса может быть получиться доказать что были некачественно выполненные работы, а может быть и нет.
Абсолютно тоже самое с 18-20.
Налоги считаются неправильно - кто штраф получит?
Вину разработчика ещё прийдется доказать, все сделано в рамках ТЗ и не колышит.

(66) а то что там что то имелось за кадром - для того же суда - не аргумент.

(62) Понимашь, поднять авто, снять одно колесо и поставить другое, может любой мужик и даже некоторые автоледи. Но!
Для того и существуют шиномонтажи и (диллерские центры), которые подразумевают, что подскажут что нужно сделать сход/развал и балансировку, а так-же расскажут о назревающих/существующих проблемах ходовой как СПЕЦИАЛИСТЫ СВОЕГО ПРОФИЛЯ!
А то что в (59) и (60) как раз таки "гаражные специалисты" срубатели бабла, накладывая пятно на всю систему шиномонтажа-франчайзи.

Твою-ж дивизию... И эти люди мне будут доказывать,что франчи - это благо?

(69) Вуася, на личности напрасно переходишь. Телепат из тебя ховно

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

(71) И это правильно, я знаю ребят, которые без подробного ТЗ с Вами просто разговаривать не будут.
Как 1сники, так и нет.
От того кто не знает что хочет - геморроя много, а толку мало

(70) На личности не перехожу, ибо личность - это один, а когда начинают кричать втригорла, что франч не обязан говорить клиенту о возможных проблемах и необходимых допработах (т.е. поменял колеса, бабло получил, а остальное проблемы пользователя) - это уже сговор.
ЗЫ. Я не претендую на лавры телепата.

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

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

(74) А простите оказывать услуги на 100 к за 10к (условно) я не нанимался, предупредил, сделал в рамках оговоренного и поофиг.

+(73) Ты специалист в 1С и должен знать, что приведет к постановке "разбалансированного колеса".
В этом случае ты либо не специалист, либо намеренно недоговариваешь, что-бы к тебе обращались еще раз уже в случае поломки, что-бы срубить еще бОльшего бабла..

(77) Если клиент мне не платит за баллансировку, то ее я делать не буду.

(78) Но ведь предложишь / скажешь что без нее будет жопа?

(79) Конечно

(80) Но по 1с - никто не слушает, все думают что они умнее, а потом плачут

(81) Именно по этому ТЗ или иди на.

(82) Как же аджайл?

(83) Аджайл не отменяет ТЗ как это не странно

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

(85) Конечно - ТЗ менее формализировано и с более коротким сроком жизни, но на каждый момент времени - требования зафиксированы

(86) Походу мы подразумеваем разное под "ТЗ" :) Работа без ТЗ можешь привести реальный кейс?

(74) (76) Это уже другая песня, когда клиент сам отказывается делать сход/развал. Возвращаюсь к начальной теме: оценка трудозатрат оп смене колеса на основании визуального осмотра.
Вот смотри. Пример из жизни.
Отвалилась у меня защита картера (ушко отвалилось). Звоню в мастерскую. Говорю Нужно приварить ушко защиты. Мне отвечают - не вопрос, приезжай. Цена? 250 рублей. ОК.
Приезжаю. Поднимают. Все окей, ща снимем, приварим и поставим на место. 250 рублей? Да 250 рублей. Один час? Да за пол часа управимся. Делаем.
Отворачиваем первый болт. Оп! обломился. Ладно разберемся. Оп! второй болт обломился. Два болта высверливать с геморойным доступом.
Ну и как тут поступать?
Ребята фигачили часа три. И выставили 750 рублей.
Ну и кто виноват в данной ситуации? Я, который запланировал затраты в обещанные 250 рублей Российский автопром, забивающий болты кувалдой? или сервис озвучивший сумму заочно?

(88) чет слишком дешево. Наверное, это не текущего года расценки.

(88) Обычно нормальные ребята при увеличении оговоренной суммы хотя бы скажут "Ну ты уже понимаешь, что тут работа не на 250 рублей"

(89) Август прошлого года. На новой машине с незакипевшими болтами это реально за час с перекурами.

(88) А что не так - цена за час озвучена.
Стандартное время тоже, но никто не обещал что уложатся.
И тут можно пойти 2 мы путями или заказать плачу по прайсу или заплатить по факту за затраченное время.

(89) Это просто тебя на иносервисах на бабки разводят

(92) и тут уже надо смотреть договор, точнее его условия.

(90) Естественно предупредили, даа и я готов был к такому (или еще худшему) развитию события.

(0) есть стандартный вариант: умножь на 2 и увеличь время на порядок, то есть с задачей, которую оцениваешь в 2 минуты реально потратишь времени 4 часа )

Че-то потерял уже нить обсуждения. Каждый про что-то свое уже :)

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

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

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

(100) Ну и я о том-же: Есть исходные данные (переписаная вхлам ТиС) и черно-серый учет со своими тараканами, на выходе должна быть УТ+CRM+Битрикс с тем-же учетом и дресироваными тараканами.
К часам это привязать невозможно.

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

Никто не хочет открыть шиномонтажку???)) Кажется, тут все есть)))

Интересно а онлайн сервис оценки трудозатрат по ТЗ можно сделать в принципе на основе ML?
Пусть и +/- километр

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

(0) Это ты расписал только предварительное планирование по видам работ, которые надо сделать. Уточнение требований, проектирование, программирование, моделирование и проверка, время на взаимодействие с клиентом, время на "инфраструктурные" вещи (например, заливка результата в хранилище заказчика, в тестовые базы), документирование, демонстрация результата, обучение, ввод в эксплуатацию и т.п.

А внутри проектирования, программирования, а также во вводе в эксплуатацию самое интересное заключается.

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

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

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

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

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

(105) Круто расписал в плане ведения проектов. Ключевое слово здесь - детализация? Максимально всё изучить до работ, зафиксировать и работать уже "по макету", грубо говоря, потому что все, что нужно делать ты уже понял заранее. Я думаю, это правильный подход для корректной оценки.
(104) Тут аналогичная мысль, как я понял.
(106) Да, так и получается, разбивать задачу на детали, складывать из них оценку и плюсовать риски. А вот цифры каждого этапа - это опыт, тут с потолка не нарисуешь))

Нашел статью на хабре. Я хз можно ли прямые ссылки оставлять, но гугл стерпит: "Оценка сроков на разработку и тестирование задачи (не нужна)". Может кому интересно будет..

(107) пхп-макакам с хабра она реально не нужна

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

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

(110) Для таких сотрудников должны быть определённые регламенты подачи заявок, управления изменениями, SLA и прочий ITIL, который не позволяет всяческим клоунам требовать "ещё вчера" реорганизации бизнес-процессов по единоличной инициативе.

+(111) И это не "настоящая работа", это авральная сборка костылей из гамна и палок.

(112) В стартапах по-другому обычно не бывает. И после такого выполненного наспех, но успешно, стартапа может последовать вкусное тиражирование.

+(113) Только вот почему-то в 1С не принято выкидывать прототип, сделанный в рамках стартапа, но брать весь опыт и делать конфетку. Обычно при тиражировании продолжают "тащить" уродца.

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

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

(115) Нигде наверное. Но много когда работать приходится именно так и это норма.

(114) ну так сделать заново  - это же один из самых главных врагов ИТ.
столько контор на этом полгорело

(117) Да не норма это, а хреново поставленные процессы в ИТ.
Когда это вот "поддержание штанов" превращается в весьма недешёвое сопровождение костыльного монстра-нетленки, будет поздно.

(119) от того что это хреново, не значит что это не может быть нормой

(107) Планирование не нужно только уборщицам, в жизни оно очень как нужно

(119) Потому что те кто писал нетленку уже ушли дальше писать другие нетленки.
А взамен наняли или остались только те кто латать дыры умеют и то готовыми заплатками из ремкомплекта.

(119) "Когда это вот "поддержание штанов" превращается в весьма недешёвое сопровождение костыльного монстра-нетленки, будет поздно."

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

(123) А я не говорю про "новый энтерпрайз", обратите внимание.
Я как раз делаю упор на том, что надо _изначально_ делать как надо, с методологией, регламентами, управлением изменениями и прочими радостями ИТ-бюрократии, чтобы не пришлось потом "новый энтерпрайз" из говна и палок собирать :)

+(124) И если новому руклю достался ещё не полный форшмак с зоопарком, он должен как можно быстрее реорганизовать работу отдела в нужном ключе. Без боя и срача не обойтись, разумеется, но это надо сделать, а не пускать "поддержание штанов" на самотёк.

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

(119) Какие процессы в стартапе? https://img.artlebedev.ru/kovodstvo/idioteka/i/FBF7053A-A349-4F4E-893E-DB2AFDEC0E4B.jpg
А если по-другому, то стартап может никогда и не выйти в свет.