Угу. А в ответ — приведите экономический рассчет, пожалуйста. Ну там оценочное количество человеко-часов умножить на ставку, мото/машино-часов умножить на амортизацию. Потом еще можно проверить — сколько было потрачено по факту. А еще можно прицениться — не будет ли дешевле этот самый склад отдать на аутсорс. Ну чтобы окончательно решить вопрос с нач. склада.
А если нач.склада — чистый, звонкий и прозрачный — тогда попал уже «заказчик».
Все это становится реальностю когда реальностью, когда пишешь код или для авиации или для атомной энергетики или для космоса. И наверно с использованием языка Ada.
Изначально проработать способ достижения достаточно подробно можно только для тех областей, для которых уже все факторы известны, измерены и их влияние можно учесть. Грубо говоря, когда проектируется здание — проектировщик опирается на наработки кучи НИИ — геологии, материаловедения и т.д. А когда работает аналитик — в ряде случаев он может только предполагать. И подтверждение можно получить только в результате НИОКР (R&D), вот только для разработки софта НИОКР стоит не сильно дешевле обычного процесса разработки. И результат зачастую зависит только от того, как задачу поймет разработчик (да-да, одну и ту же самую задачу можно решить по разному). А расписать задачу до однозначности — требует столько же, а иногда и больше, времени сколько требуется на реализацию разработчику.
Собственно вся индустрия стартапов построена на том факте, что гигантские корпорации с многотысячными штатами, многомиллиардными бюджетами, зрелыми процессами, аналитиками, энтерпрайз архитекторами, «отделами разработки» и «отделами эксплуатации» не в состоянии воспроизвести путь маленькой быстро адаптирующейся команды стартапа за разумное время и с приемлемым бюджетом. Просто потому, что маленькая команда может потыкать пальцем в небо очень быстро и в результате таки нащупать там новый рынок или источник дохода.
У большой системы в принципе не может быть единого собственника. В том бизнес-юните или департаменте или направлении (ага, тайтлы менялись), в котором работал я — работало еще более сотни одних только разработчиков. О некоторых частях системы я имел весьма теоретическое понятие — просто потому, что там изменения происходили чаще, чем я заглядывал в эту часть системы. Или смотришь — идут данные от чего-то с забубенной аббревиатурой, вроде один продукт, глянул на доки — а там еще одна система состоящая из кучи продуктов с не менее забубенными аббревиатурами. (Продуктом мы называли минимальную развертываемую функциональность, чаще всего один, иногда несколько системных пакетов. По факту один продукт мог разворачиваться на кластере в несколько десятков апп хостов и требовать под себя пару-тройку дб кластеров.) К одному человеку все сводилось уже довольно далеко от разработки. И этот человек, условно, собственник — не бегает за пользователями — у него для этого есть отдел продаж. И куча менеджеров для внутренних коммуникаций.
А менеджер по работе с клиентами вообще-то тоже один из непрямых (через несколько слоев линейных менеджеров) подчиненных условного собственника. И ко мне он пришел не напрямую, а получив контакт от моего менеджера. Просто я был одним из знающих свой кусочек системы, берущих на себя ответственность за фичу и умеющих полный цикл — от сбора требований до вывода на продакшн.
Ну я бы сказал, что даже не перед бизнесом, а перед другими опсами. Вообще я более полутора лет выпрашивал человека от опсов в команду с двумя целями — представлять опсов при разработке каждой фичи в команде и представлять команду при общении с опсами.
Далеко не всегда при разработке учитывается точка зрения опсов (ну или то, что разработчик считает точкой зрения опсов). Особенно без напоминания. И внести изменения в написанную, задокументированную и протестированную фичу через пару месяцев после завершения работы над ней — гораздо сложнее чем поменять ее сразу после написания.
И команда не всегда готова принять запрос на фичу — что при ватерфолле, что при скраме. При ватерфолле команда открыта к запросам только на этапе до фиксирования скоупа. А в периоды релиза — вообще лучше не трогать. При скраме — только в моменты подготовки к планированию. В беклог то запрос добавят в любой момент, но не факт, что запрос будет понятен, а человек умеющий задавать правильные вопросы — будет свободен.
Проблема как раз в том, что управления рисками нет. Есть процесс максимально снижающий риски и его начинают применять повсюду. Даже когда он никак не влияет на риски — все равно используют его. И тратить полтора месяца на деплоймент мелкого изменения веб юая доступного только внутренней команде (спонсор проекта имел достаточный вес чтобы запустить процесс релиза с одной единственной фичей) — это весьма неэкономично. Но происходит — потому что опсы предпочитают перестаховаться в связи с незнанием продукта и команды, невозможностью оценить риски из-за своего незнания.
Это реальный процесс, в той форме в которой он самостабилизируется. В той форме которую он приобретает в результате взаимодействия с другими процессами. До единого владельца там толстый-толстый слой линейных менеджеров. В том числе и «прекрасно сертифицированных» специалистов по процессам с «огромным опытом».
Проблема в том, что наличие этого процесса как и других никак не коррелирует с достижением цели поставленной бизнесом. А вот количество попыток достижения цели — коррелирует. Каждый релиз — это попытка, которая дает информацию, что же неверного было в начальных предпосылках. В результате — чем больше было сделано релизов, тем ближе фактический результат проекта к ожидаемому. А это как раз критерий оценки проекта с точки зрения бизнеса.
К сожалению, сведение все к абстрактным «службам» и взаимодействию между ними приводит к катастрофическим последствиям.
Вообще сталкивался с шикарным случаем — большая международная корпорация, процессы прописаны от и до, все регламентировано и прекрасно формализированно. Разработчик написал некий функционал, но бюрократию не осилил, так что запустил свое творение на одном из шаред дев серверов. Все прекрасно работало, данные генерились даже после увольнения разработчика более года. Пока сервером не перестали пользоваться другие разработчики. Сервер погасили и данные перестали генериться — началось расследование что за фигня. Нашли причину, сервер подняли обратно и начали думать что делать дальше. Решили «продуктизировать» функционал в виде отдельного продукта и досталась эта работа мне. И вот этот проект «продуктизации» занял более четырех месяцев! Протащить готовый функционал через все необходимые процессы с написанием и подписанием всех необходимых документов (спека на функционал была написана оригинальным разработчиком, так что все остальные докумены — производные от нее) — более четырех месяцев!!!
Там в компании вообще все печально — банально выкатить релиз на стейдж это: написать стейдж деплоймент гайд (часа 2-3 с паралельным деплойментом в дев энвайроменте); разобраться кто должен подписать этот гайд в этот раз (часов примерно 5) и создать ревью; пинать подписантов до победного конца (недели полторы-две); подождать очередного планнига опсов (1-4 дня); подождать самого деплоймента (1-2 дня); понаблюдать за деплойментом (до 1 часа) скрестив пальцы чтобы в этот раз опс осилил копипаст из гайда в терминал без самодеятельности (бывали преценденты с заходом на продакшн хост вместо стейджа, при том, что в гайде даже ссш команды с правильными именами хостов прописаны). Для продакшна — повторить.
И когда менеджер по работе с клиентами приходил ко мне с пустяковым запросом — минимальный срок я выставлял в полтора месяца. И пояснял — 20 минут на оформление запроса, 5 минут на изменение в коде, 30 минут на тестирование, две недели на подготовку стейдж деплоймента, две недели на стейдже, две недели на подготовку продакшн деплоймента. Более быстрый процесс — только через аварийный деплоймент с визой руководителя на три уровня выше моего начальника. Оптимизация — невозможна, невовремя созданные ревью документов — закрываются как нарушающие процесс. Подписать ревью быстрее чем за полторы-две недели — только с помощью того самого руководителя на три уровня выше моего начальника, у остальных область накрытия живительного пинка маловата.
Причем раньше было хуже — кьюэи были отделены такой же бюрократической стеной как опсы и добавляли от двух до четырех недель на тестирование. Но удалось их втащить в процесс разработки — с автоматической регрессией и добавленим/изменением кейсов сразу по изменению кода.
Цинично отмечу, что «служба эксплуатации» это не первая, а вторая производная от бизнеса. Первая производная — это «служба разработки». «Служба эксплуатации» создается чтобы сэкономить на девелоперах — за счет найма более дешевых опсов, которые возьмут на себя часть работы девелоперов по поддерке продукта.
Даже когда покупается готовое решение — все равно его кто-то разработал и при этом уже произвел подготовку к передаче в эксплуатацию (что включается в цену). Когда разработка ведется в рамках компании — издержки на передачу в эксплуатацию теоретически должны снижаться, но при возникновении разногласий между разработкой и эксплуатацией — они могут даже увеличится. А дальше бизнес смотрит просто — где меньше затраты — когда девелоперы занимают поддержкой или когда девелоперы передают продукт выделенному отделу эксплуатации.
Вроде бы правильные слова про документирование — на самом деле означают создание дополнительной документации специально для опсов. Вроде как документацию для опсов должны писать опсы, но они не могут, потому что ничего не знают и вешают эту нагрузку на девелоперов. И причина проста — опсы не участвовали в разработке и не разбираются в уже существующей документации и продукте. При этом девелоперы пишут простую и понятную со своей точки зрения документация для опсов, а опсы в ней не могут разобраться и усложняют требования к документированию. А это в свою очередь требует больше времени и в результате увеличивает издержки на передачу в эксплуатацию — потому что девелоперы занимаются не своей основной работой, а писательством на заказ. Ну а дальше — эксперименты направленные на вовлечение в процесс разработки опсов, вплоть до переименовывания их в девопсов.
Ну тут по хорошему надо совсем не штрихкод вводить. Надо осознать, что внутри склада происходит гораздо больше действий, чем отображено в модели склада используемой в бухгалтерии. И складу нужна собственная система автоматизации основанная на модели отражающей реальные движения внутри склада. И складскому работнику нужны его собственные документы, просто эти документы можно автоматически генерировать на основании входящих бухгалтерских документов. И так же автоматически генерировать бухгалтерские документы на основании внутрискладских. Ну а мелкое исправление в бухгалтерском документе вполне может быть основанием для большого количества внутрискладских движений — и эти движения должны быть отражены в внутрискладских документах (да, потому что люди будут работать и эта работа будет оплачена). И по факту склад может быть перегружен из-за постоянных пересортировок, а для внешнего наблюдателя — склад работает очень медленно, но причина в документах не видна.
Конкретная реализация внутрискладских документов уже может быть выражена в виде листа действий грузчика.
Взять лоток типа 123, пройти в 3 проход до 8 стеллажа и с 4 полки взять 3 единицы товара ХХХ (фото одной единицы), после этого пройти до 12 стеллажа и с 4 полки взять 1 единицу товара УУУ (фото), лоток вынести к окну выдачи 5.
Взять грузовую тележку инв. номер 12345 с места хранения АБВ, пройти до… и т.д.
Или у грузчика могут быть очки дополненной реальности с камерой.Тогда он может получать указания динамически — куда идти, что брать, сколько единиц. Это не требует большого разрешения и качественной графики — одна-две текстовых строки на 20-30 символов, возможно голосовой ассистент-навигатор.
Ну и если денег много, склад огромный, номенклатура гигантская, движение по складу бешеное — смотри склад Амазона ;)
Остро не хватает объяснения, что же на самом деле ожидалось от тимлида. Попадание в сроки определенные до начала проекта? Так скрам не про это. Отвертка вообще плохо подходит для забивания гвоздей, равно как и молоток не тот инструмент который нужен для заворачивания шурупов. Скрам хорош для контроля производительности при тайм-энд-материал проектах. А для фиксед прайс — больше подходит руп или тот же ватерфолл. И вообще-то там есть понятие НИОКР (R&D) проектов для неясных случаев. Когда фиг его знает — достижимы ли заявненные цели в задекларированных условиях в принципе. Ну а когда менеджмент подписывает контракт с фиксированной стоимостью и сроками и допускает внесение изменений в объем работ без пересмотра этой самой стоимости и сроков — это клиника. Тут самый лучший исполнитель ничего не сможет сделать. Есть конечно варианты когда исполнитель самовольно соглашается на изменение объема работ — но это опять таки ошибка менеджера допустившего такую самодеятельность. Ну и цинично отмечу, что тимлид это не менеджер, ему желательно, но не обязательно знать все вышесказанное. А уж свежеповышенный тимлид тем более.
Вообще, если планируется работать с лидом дальше — нужен нормальный анализ ошибок проекта с выделением областей применимости вышеупомянутых инструментов и техник. А в приведенной форме это выглядит как классическая манипуляция с созданием чувства вины у выбранного стрелочника и последущим забалтыванием для затирания аргументации и закрепления чувства вины. Поэтому я и не люблю работу в офисе с коммуникацией не подразумевающей ведение истории (правда у меня значительный опыт удаленной работы аутсорсером и есть возможность сравнивать). Личностей мнящих себя непревзойденными манипуляторами (или просто очень хитрыми и умными) — множество, тратить время на борьбу с манипуляциями не очень то и продуктивно. А наличие истории общения по крайней мере сдерживает самых тупых — потому что полные идиоты выпиливаются моментально.
Люди фактически делают работу бизнес-аналитиков по документированию рабочих процессов — а глав-автоматизатор не понимает, что у него под носом происходит. Там только добавить взаимосвязь задач и можно выписывать фактически существующие процессы под автоматизацию. Имея задокументированный процесс — его уже можно рефакторить, а имея автоматизцию процесса — внедрять изменение становится гораздо проще.
А если еще добавить учет потраченного на задачу времени…
Интересно, в какой серии появится формулировка — расхождение модели в информационной системе и реальности.
Дальше будут качели — изменения в модели и реальности. Реальность сложна, попытка в лоб привести реальность к модели — приводит к росту бюрократизации и в конце концов проваливается из-за слишком больших накладных расходов на внесение данных в информационную систему. Попытка отразить реальность в модели — ведет к усложнению модели до полной неприменимости. Но каждая итерация порождает островки равновесия между сложностью модели и формализации реальности. Типа производственных линий и конвейеров, автоматизированных складов (Амазон и последователи), CRM, ERP и автоматизации бухгалтерии.
Если говорить конкретно о примере в серии статей, то одним из решений проблемы склада будет выделение части номенклатуры в склад особого учета с задроченными до состояния биороботов работниками (ну или с частичной или полной автоматизацией) и усложненной моделью в информационной системе. Естественно, внедрение и эксплуатация такого склада будет дороже обычного склада, поэтому предварительно надо будет произвести расчет расходов и издержек и уже их сравнить с ожидаемым повышением прибыли. Вполне может оказаться, что это решение экономически невыгодно в момент оценки и бардак останется нетронутым. Перерасчет решения можно производить периодически и/или при появлении/изменении существенных факторов (ну например появление в продаже роботизинованных складов с подходящими параметрами единиц хранения — веса и размера).
Интересно, сколько сейчас людей, какова организационная структура, распределение обязанностей и насколько разнородные проекты.
Просто проекты бывают разные — добавить несколько полей к табличке или хоткеи к скрину (и еще 99 подобных несвязанных изменений в рамках одного проекта), миграция многосервисной системы с HP Blades на VMs, миграция между датацентрами (ага, перенос системы состоящей из кучи сервисов и перемалывающей терабайты данных в сутки занял более полугода зато даже физическое повреждение основного оптоволоконного канала между датацентрами осталось незаметным для клиентов). Некоторые не запускаются вообще — после сбора реквайрментов (например инициатор тихо слился без объяснения как баззворды соединить так, чтобы получить прибыль) или оценки необходимых вложений («Собрать месячный архив для постобработки вполне реально, но потребуется не менее 60ТБ хранилища потому, что сейчас обрабатывается потоково 2ТБ данных в сутки. Может аналитики воспользуются одним из существующих инструментов фильтрации потока данных или объяснят чего именно не хватает в существующих инструментах?» И внезапно оказалось, что аналитики забыли о существовании этих инструментов).
P.S. Про палки забудьте, если не хотите получить дикие оверестимейты и партизан в гестапо. Дейли скрамы они не про отчет перед всей командой, они для информирования о прогрессе. И не ошибается тот, кто ничего не делает.
А если нач.склада — чистый, звонкий и прозрачный — тогда попал уже «заказчик».
Собственно вся индустрия стартапов построена на том факте, что гигантские корпорации с многотысячными штатами, многомиллиардными бюджетами, зрелыми процессами, аналитиками, энтерпрайз архитекторами, «отделами разработки» и «отделами эксплуатации» не в состоянии воспроизвести путь маленькой быстро адаптирующейся команды стартапа за разумное время и с приемлемым бюджетом. Просто потому, что маленькая команда может потыкать пальцем в небо очень быстро и в результате таки нащупать там новый рынок или источник дохода.
У большой системы в принципе не может быть единого собственника. В том бизнес-юните или департаменте или направлении (ага, тайтлы менялись), в котором работал я — работало еще более сотни одних только разработчиков. О некоторых частях системы я имел весьма теоретическое понятие — просто потому, что там изменения происходили чаще, чем я заглядывал в эту часть системы. Или смотришь — идут данные от чего-то с забубенной аббревиатурой, вроде один продукт, глянул на доки — а там еще одна система состоящая из кучи продуктов с не менее забубенными аббревиатурами. (Продуктом мы называли минимальную развертываемую функциональность, чаще всего один, иногда несколько системных пакетов. По факту один продукт мог разворачиваться на кластере в несколько десятков апп хостов и требовать под себя пару-тройку дб кластеров.) К одному человеку все сводилось уже довольно далеко от разработки. И этот человек, условно, собственник — не бегает за пользователями — у него для этого есть отдел продаж. И куча менеджеров для внутренних коммуникаций.
А менеджер по работе с клиентами вообще-то тоже один из непрямых (через несколько слоев линейных менеджеров) подчиненных условного собственника. И ко мне он пришел не напрямую, а получив контакт от моего менеджера. Просто я был одним из знающих свой кусочек системы, берущих на себя ответственность за фичу и умеющих полный цикл — от сбора требований до вывода на продакшн.
Далеко не всегда при разработке учитывается точка зрения опсов (ну или то, что разработчик считает точкой зрения опсов). Особенно без напоминания. И внести изменения в написанную, задокументированную и протестированную фичу через пару месяцев после завершения работы над ней — гораздо сложнее чем поменять ее сразу после написания.
И команда не всегда готова принять запрос на фичу — что при ватерфолле, что при скраме. При ватерфолле команда открыта к запросам только на этапе до фиксирования скоупа. А в периоды релиза — вообще лучше не трогать. При скраме — только в моменты подготовки к планированию. В беклог то запрос добавят в любой момент, но не факт, что запрос будет понятен, а человек умеющий задавать правильные вопросы — будет свободен.
Проблема в том, что наличие этого процесса как и других никак не коррелирует с достижением цели поставленной бизнесом. А вот количество попыток достижения цели — коррелирует. Каждый релиз — это попытка, которая дает информацию, что же неверного было в начальных предпосылках. В результате — чем больше было сделано релизов, тем ближе фактический результат проекта к ожидаемому. А это как раз критерий оценки проекта с точки зрения бизнеса.
Вообще сталкивался с шикарным случаем — большая международная корпорация, процессы прописаны от и до, все регламентировано и прекрасно формализированно. Разработчик написал некий функционал, но бюрократию не осилил, так что запустил свое творение на одном из шаред дев серверов. Все прекрасно работало, данные генерились даже после увольнения разработчика более года. Пока сервером не перестали пользоваться другие разработчики. Сервер погасили и данные перестали генериться — началось расследование что за фигня. Нашли причину, сервер подняли обратно и начали думать что делать дальше. Решили «продуктизировать» функционал в виде отдельного продукта и досталась эта работа мне. И вот этот проект «продуктизации» занял более четырех месяцев! Протащить готовый функционал через все необходимые процессы с написанием и подписанием всех необходимых документов (спека на функционал была написана оригинальным разработчиком, так что все остальные докумены — производные от нее) — более четырех месяцев!!!
Там в компании вообще все печально — банально выкатить релиз на стейдж это: написать стейдж деплоймент гайд (часа 2-3 с паралельным деплойментом в дев энвайроменте); разобраться кто должен подписать этот гайд в этот раз (часов примерно 5) и создать ревью; пинать подписантов до победного конца (недели полторы-две); подождать очередного планнига опсов (1-4 дня); подождать самого деплоймента (1-2 дня); понаблюдать за деплойментом (до 1 часа) скрестив пальцы чтобы в этот раз опс осилил копипаст из гайда в терминал без самодеятельности (бывали преценденты с заходом на продакшн хост вместо стейджа, при том, что в гайде даже ссш команды с правильными именами хостов прописаны). Для продакшна — повторить.
И когда менеджер по работе с клиентами приходил ко мне с пустяковым запросом — минимальный срок я выставлял в полтора месяца. И пояснял — 20 минут на оформление запроса, 5 минут на изменение в коде, 30 минут на тестирование, две недели на подготовку стейдж деплоймента, две недели на стейдже, две недели на подготовку продакшн деплоймента. Более быстрый процесс — только через аварийный деплоймент с визой руководителя на три уровня выше моего начальника. Оптимизация — невозможна, невовремя созданные ревью документов — закрываются как нарушающие процесс. Подписать ревью быстрее чем за полторы-две недели — только с помощью того самого руководителя на три уровня выше моего начальника, у остальных область накрытия живительного пинка маловата.
Причем раньше было хуже — кьюэи были отделены такой же бюрократической стеной как опсы и добавляли от двух до четырех недель на тестирование. Но удалось их втащить в процесс разработки — с автоматической регрессией и добавленим/изменением кейсов сразу по изменению кода.
Даже когда покупается готовое решение — все равно его кто-то разработал и при этом уже произвел подготовку к передаче в эксплуатацию (что включается в цену). Когда разработка ведется в рамках компании — издержки на передачу в эксплуатацию теоретически должны снижаться, но при возникновении разногласий между разработкой и эксплуатацией — они могут даже увеличится. А дальше бизнес смотрит просто — где меньше затраты — когда девелоперы занимают поддержкой или когда девелоперы передают продукт выделенному отделу эксплуатации.
Вроде бы правильные слова про документирование — на самом деле означают создание дополнительной документации специально для опсов. Вроде как документацию для опсов должны писать опсы, но они не могут, потому что ничего не знают и вешают эту нагрузку на девелоперов. И причина проста — опсы не участвовали в разработке и не разбираются в уже существующей документации и продукте. При этом девелоперы пишут простую и понятную со своей точки зрения документация для опсов, а опсы в ней не могут разобраться и усложняют требования к документированию. А это в свою очередь требует больше времени и в результате увеличивает издержки на передачу в эксплуатацию — потому что девелоперы занимаются не своей основной работой, а писательством на заказ. Ну а дальше — эксперименты направленные на вовлечение в процесс разработки опсов, вплоть до переименовывания их в девопсов.
Конкретная реализация внутрискладских документов уже может быть выражена в виде листа действий грузчика.
Взять лоток типа 123, пройти в 3 проход до 8 стеллажа и с 4 полки взять 3 единицы товара ХХХ (фото одной единицы), после этого пройти до 12 стеллажа и с 4 полки взять 1 единицу товара УУУ (фото), лоток вынести к окну выдачи 5.
Взять грузовую тележку инв. номер 12345 с места хранения АБВ, пройти до… и т.д.
Или у грузчика могут быть очки дополненной реальности с камерой.Тогда он может получать указания динамически — куда идти, что брать, сколько единиц. Это не требует большого разрешения и качественной графики — одна-две текстовых строки на 20-30 символов, возможно голосовой ассистент-навигатор.
Ну и если денег много, склад огромный, номенклатура гигантская, движение по складу бешеное — смотри склад Амазона ;)
Вообще, если планируется работать с лидом дальше — нужен нормальный анализ ошибок проекта с выделением областей применимости вышеупомянутых инструментов и техник. А в приведенной форме это выглядит как классическая манипуляция с созданием чувства вины у выбранного стрелочника и последущим забалтыванием для затирания аргументации и закрепления чувства вины. Поэтому я и не люблю работу в офисе с коммуникацией не подразумевающей ведение истории (правда у меня значительный опыт удаленной работы аутсорсером и есть возможность сравнивать). Личностей мнящих себя непревзойденными манипуляторами (или просто очень хитрыми и умными) — множество, тратить время на борьбу с манипуляциями не очень то и продуктивно. А наличие истории общения по крайней мере сдерживает самых тупых — потому что полные идиоты выпиливаются моментально.
А если еще добавить учет потраченного на задачу времени…
Дальше будут качели — изменения в модели и реальности. Реальность сложна, попытка в лоб привести реальность к модели — приводит к росту бюрократизации и в конце концов проваливается из-за слишком больших накладных расходов на внесение данных в информационную систему. Попытка отразить реальность в модели — ведет к усложнению модели до полной неприменимости. Но каждая итерация порождает островки равновесия между сложностью модели и формализации реальности. Типа производственных линий и конвейеров, автоматизированных складов (Амазон и последователи), CRM, ERP и автоматизации бухгалтерии.
Если говорить конкретно о примере в серии статей, то одним из решений проблемы склада будет выделение части номенклатуры в склад особого учета с задроченными до состояния биороботов работниками (ну или с частичной или полной автоматизацией) и усложненной моделью в информационной системе. Естественно, внедрение и эксплуатация такого склада будет дороже обычного склада, поэтому предварительно надо будет произвести расчет расходов и издержек и уже их сравнить с ожидаемым повышением прибыли. Вполне может оказаться, что это решение экономически невыгодно в момент оценки и бардак останется нетронутым. Перерасчет решения можно производить периодически и/или при появлении/изменении существенных факторов (ну например появление в продаже роботизинованных складов с подходящими параметрами единиц хранения — веса и размера).
Просто проекты бывают разные — добавить несколько полей к табличке или хоткеи к скрину (и еще 99 подобных несвязанных изменений в рамках одного проекта), миграция многосервисной системы с HP Blades на VMs, миграция между датацентрами (ага, перенос системы состоящей из кучи сервисов и перемалывающей терабайты данных в сутки занял более полугода зато даже физическое повреждение основного оптоволоконного канала между датацентрами осталось незаметным для клиентов). Некоторые не запускаются вообще — после сбора реквайрментов (например инициатор тихо слился без объяснения как баззворды соединить так, чтобы получить прибыль) или оценки необходимых вложений («Собрать месячный архив для постобработки вполне реально, но потребуется не менее 60ТБ хранилища потому, что сейчас обрабатывается потоково 2ТБ данных в сутки. Может аналитики воспользуются одним из существующих инструментов фильтрации потока данных или объяснят чего именно не хватает в существующих инструментах?» И внезапно оказалось, что аналитики забыли о существовании этих инструментов).
P.S. Про палки забудьте, если не хотите получить дикие оверестимейты и партизан в гестапо. Дейли скрамы они не про отчет перед всей командой, они для информирования о прогрессе. И не ошибается тот, кто ничего не делает.