Pull to refresh

Comments 35

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

К сожалению надвигающаяся цифровизация делает режим электровеника всё более актуальным для всех отраслей и типов проектов
Комментарий пользователя dralexnone к публикации «График проекта vs Бэклог: битва без шансов» ожидает вашего одобрения:

Очередная утопия. Agile очень хорош для доработок в рамках уже работающего решения. Попробуйте построить Новый дом без плана-проекта-графика или корабль. У Agile есть множество недостатков и два принципиальных:1) c помощью мелких итераций и короткого планирования невозможно избежать архитектурных и концептуальных ошибок 2) невозможно приемлемо оценить бюджет проекта из-за плохой оценки рисков и наполнения бэклога.
Поэтому стартовый грамотный концепт — обязателен, учет архитектурных рисков — также. Классический пример: не учли целевой объем данных и прекрасный по «фичам» проект «не взлетел» из-за бесконечных задержек и блокировок… Переписывать придется с нуля. И таких примеров десятки — любой сложный проект с «нуля» попадает в эту категорию.

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

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

Вы отвечаете на непринятый Вами комментарий… Зачем? И если считаете уместным принимайте и обсуждайте.
То ли техническая неисправность, то ли я нажал не туда — почему-то комментарий удалился, а я хотел бы ответить
Вы согласовываете общие высокоуровневые KPI и начинаете проект

А можно пример? Нельзя же прийти к спонсору и сказать «Ну вы дайте денег, мы начнем, а там посмотрим». Они же хотят посчитать ROI, а без оценки денег и времени этого нельзя сделать.
Нет, ну ROI можно посчитать без детального графика проекта с таким же уровнем точности, как и без оного. И в том и в том случае точность будет не идеальна, но в случае если ROI расчитан на базе графика проекта, то тот становится практически отлитым в граните и потом начинается подгонялово проектных решений под график а не наоборот.
Можно поподробнее, как вы посчитаете ROI на подобном проекте?
Допустим проект — создать рекламный сайт. Экспертно и по бенчмаркингу определяем, сколько приблизительно затраты на создание, на сколько приблизительно он увеличит траффик и объёмы продаж, считаем прибыль. Из общего дохода вычитаем сумму инвестиций, получая конечную прибыль, и делим результат на сумму инвестиций. Умножаем на 100, чтобы получить результат в процентах.
На первый же (ну окей на второй) УК вы притаскиваете этих своих недопиленных уродцев, не стесняясь ничуть. Ведь это ПРОТОТИПЫ!

Вы заблуждаетесь MVP — это не прототип. Это конечный продукт и к его созданию нужно подходить как к конечному продукту. Так что делать его на до "на совесть" и "отвечать за свою работу". А принцип что будет готово тогда, когда будет готово, приносят как раз гибкие методологии.


Гибкие методологии хорошо работают когда нет четкого понимания, что требуется в конечном итоге, а есть лишь направление движения. В случае когда цели и требования известны, и не меняются, то "график проекта" (каскадная модель, waterfall model) прекрасно работает. А при граммотном проектировании, продукт будет дешевле, чем при использовании гибких методологий.


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


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

Вы заблуждаетесь MVP — это не прототип

Концептуально в рамках контекста — это одно и тоже, если в финальном варианте продукт подразумевается как набор сложных функций, но его построение можно строить на базе MVP.

Но вообще это разные понятия, согласен.

Тут акцент на определённости конечного продукта. Если вы дом по типовому проекту строите, то план проекта отработает лучше.


Плюс вы немного подменили обсуждение методики управления на постановку требований. А корень проблемы даже не в них, а в адекватности Заказчика stakeholders (кем бы они ни были) и управлении этими товарищами PM/POом. Если эти кеи сами не могут сформулировать ожидания от конечного результата и лезут лично и постоянно в микроменеджмент, то даже в Agile вам обеспечена изрядная доля веселья. Просто не потратите время на перерисовку графика.

Вы заблуждаетесь MVP — это не прототип. Это конечный продукт и к его созданию нужно подходить как к конечному продукту. Так что делать его на до «на совесть» и «отвечать за свою работу». А принцип что будет готово тогда, когда будет готово, приносят как раз гибкие методологии.


Конечно MVP бывают разные.
Представьте, вы оказались в небольшом городке. Там нет пиццерий.
У вас родился гениальный план, открыть пиццерию.
Для того чтобы проверить, будут ли охотно покупать жители городка пиццу, необязательно открывать пиццерию. Можно дома в печке выпечь несколько штук. Или купить в соседнем городе и привести. Или арендовать передвижную пиццерию. Или… (прочие варианты)

Agile — он не про ИТ. Agile — про бизнес.
Цель — проверить идею на жизнеспособность. А что нужно для этого, mvp сделанный на совесть, или схемка на салфетке, зависит от контекста.
Agile — он не про ИТ. Agile — про бизнес.


Аминь!
И в этом случае надо делать на совесть. Просто нужно понять, что в данном случае будет MVP. Для доставки на дом/продажи готовой — это будет одно, для кафе — набор требований будет другим, но все это будет MVP и надо делать на совесть. Выбрать качественный ингредиенты, соблюдать требования СанПин и пожарной безопасности, при найме сотрудников соблюдать ТК. Вот это все я и называю работать на совесть.

Если говороть об ИТ, то покрывать продукт тестами, не выбирать заведомо тупиковые решения, но делать только то, что нужно в данный момент, использовать хорошие практики CI/CD.

Это как пилотные серии сериала — никто не планирует заранее сколько сезонов и серий будет снято, а создают их по необходимости. Так же и с кафе, открывается что-то совсем маленькое и потом растет-растет. Но если сделать первые серии сериала абы как, то никто не будет смотреть дальше, так же и если готовить абы как, то никто не захочет это есть.
Конечно качественно. Другое дело, что понятие качественно для всех разное. В статье я имел в виду, что демонстрироваться должны базовые функции бехз маркетинговых фишечек и WOW-факторов. Профессионалам будет достаточно, а вот некоторые конечные юзеры возможно подумают, что это «недопиленные уродцы»
MVP бывают разные… же…

Да, с СЭСом шутить не надо. Но не везде нужен СЭС.

Опять вспомним про пиццерию.
Вот открыли вы пиццерию. И у вас новая гениальная мысль, принимать заказы через телеграм, со всеми делами (чатботы, ML, блокчейн и прочие шняги). Что для проверки идеи нужно? Да ничего не нужно. Открываете канал, садите девочку мониторить канал и переносить заказы в… (где там у вас заказы живут).
С точки зрения ИТ есть MVP? Наверно нет, по ИТ же ничего не сделано.
С точки зрения бизнеса есть MVP? Можно робко предположить что есть. Ведь цель — проверить, а много ли будет заказов через телеграм, есть ли подводные камни. нравится ли клиентам заказывать через телеграм, ну и прочее в таком духе. Вы решаете бизнес-проблему, а не ИТ.

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


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

«Вы согласовываете общие высокоуровневые KPI и начинаете проект» — у вас есть success story такого подхода в реальных бюрократизированным организациях, где одновременно десятки проектов, а еще сотни «проектных инициатив»? Очень хотелось бы увидеть реальные примеры этих самых «высокоуровневых KPI», которые удалось согласовать в такой организации.
Работать по agile, отталкиваясь от высокоуровневых KPI — удобно, практично и эффективно.
И если вам такой подход не дают применять ваши забюрократизированные структуры руководства, то, согласитесь, это вина этих структур, а не подхода.
Значит надо пытаться донести выгоду и преимущества работы по agile до руководства и менять культуру организации (кстати инструментов для этого в Agile тоже предостаточно)
Спасибо за комментарий. И все-таки, хотелось бы увидеть примеры согласованных высокоуровневых KPI. Сможете привести?
Приведите пример проекта, а я напишу какие в нем можно определить высокоуровневые КПЭ. Просто чтобы оперировать понятиями из ваших реалий
Наверное, с этого вопроса стоило начать, но лучше поздно, чем никогда...:)
Вы изложили некую теорию («надо делать вот так») или свой реальный опыт («а я сделал вот так и — PROFIT!»)? Если реальный опыт — то мне было бы очень интересно увидеть конкретные примеры высокоуровневых KPI.
Понятно. Но я поэтому и спрашивал про ваш проект, потому что все мои реальные примеры не из IT я внедряю Agile в другой отрасли.

Но если говорить о моих реальных примерах сейчас, то это будет: «Разработать систему учёта и регистрации простоев», «повысить КТГ на 10%» и т.д. В общем операционная эффективность. Но в своё время был опыт работы на проектах внедрения IT-систем, и могу сказать, что мы могли бы тогда избежать многих проблем, если бы знали про agile
А теперь осталось применить эту систему к самому проекту бюджета (вполне себе проект)
Результат чистого agile вполне предсказуем — «попилим что дадут, на ближайшие 3мес назначим себе зарплату на лучшем уровне от Google (а почему нет? — в бэклоге всего мало, проект крут, сделаем быстро, все успеем, все довольны)… „
И ожидаемо (как раз через 3 месяца) вся шабашка пойдет искать новый проект
«Проект бюджета» — это всё-таки не «проект внедрения») хоть слова и похожи.
Agile это всё-таки инструмент организации взаимодействия людей. Но если вы хотите организовать обширное согласование «проекта бюджета», то эту деятельность можно построить в духе Agile. Работа короткими итерациями никак не станет причиной «попилим бюджет».

НУ или вы как-то неправильно понимаете Agile
ИМХО, форма повествования просто за уши притянула подобный вывод. Точно так же можно привязать победу четко структурированному, описанному и аргументированному графику проекта, где все стремятся соблюдать сроки, против беклога, где вообще никто не хочет глядеть дальше собственного (носа) таска.
Сделайте объективное сравнение этих методологий и поймете, что в реальности все равно между ними нужно выбирать тот инструмент, который подойдет под конкретные условия…
Не знаю, я пытался быть объективным в сравнении. Приведите, пожалуйста, пример, когда, на ваш взгляд, график проекта будет эффективнее бэклога.
Когда необходимо представить решение по фиксированной цене. Для этого необходимо оценить конкретные итерации, как по времени, так и по бюджету. И соответственно, нужно будет в них попадать, иначе никто вам не заплатит.
Да но для выдерживания сроков agile тоже хорош. Теоретически если все операции проекта так предсказуемы и идентичны, что каждому члену нужно просто садиться и делать их с достаточной быстротой без привлечения и интерактива с другими людьми и необходимости учитывать их пожелания, то да, эджайл там не нужен, но это не проект тогда а конвейер.
А в реалиях я никогда не видел, чтобы какойнибудь мало-мальски крупный проект внедрялся без многочисленных согласований, изменений требований и т.д. чтобы можно было сразу распланировать его от начала и до конца.

Много написано, я попробую на все ответить.
— agile это в первую очередь инструмент, и с его помощью можно и выдерживать сроки в том числе
— Практически любую задачу можно декомпозировать и оценить время работы над каждой задачей. Это вполне можно сделать
— работа по фиксированной цене как раз и подразумевает определенное количество хотелок. Либо все хотелки вносятся в дополнительный счет.
— проект крайне редко и далеко не во всех аспектах является изобретательством. Тем не менее, к конвейеру это не имеет никакого отношения. Ни один из проектов, в котором я учавствовал, не являлся крайней точкой в отрезке «конвейер — изобретательство».
— «Я никогда не видел» — это очень плохой аргумент. И даже согласования никак не отменяют один большой скоуп задач на весь проект. Далеко не каждая разработка требует наличие Инкремента, Спринта и других артефактов аджайла. И дело тут совсем не в рамере.
— Вопрос планирования разработки — сугубо в компетенции разработчиков. Сеньору в области разработки вполне под силу декомпозировать и оценить бытовые задачи — подавляющее большинство из них он либо решал, либо знает, как решать.
— Удивительно, но разработка даже сложных систем — далеко не всегда для программиста «творческая» задача. За долгие годы успеваешь увидеть столько, что в общем то мало что удивляет.
— В общем гибкая методология — она вообще не маст хев. Это хороший инструмент, впрочем, как и все другие популярные инструменты.
Очевидно же, когда бэклог будет неэффективнее графика. Как такое может быть? Ну например когда задачи в бэклоге противоречат друг другу, а выясняется это по ходу дела, потому что в голове держать всё — такого человека нет. Или например все таски имеют мажор/критикал приоритеты и лежат и тухнут месяцами/годами. Еще вариант когда со стороны заказчика эксперт в бизнес-области уходит, а появившиеся на его месте просят отреверсить код чтобы восстановить логику, а полноценного документа нет, только скудные наметки в трекере. Отдельный момент — конфликты по оценки трудозатрат с заказчиком. Тот просит сделать «мелкую но важную фигню», а ему выкатывают срок два месяца.

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

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

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

Отдельный момент — конфликты по оценки трудозатрат с заказчиком. Тот просит сделать «мелкую но важную фигню», а ему выкатывают срок два месяца.

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

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


Вот тут полностью соглашусь, внедрение в стиле «карго-культ» — это широкая практика и именно такие внедрения дают Agile плохое имя.
Sign up to leave a comment.

Articles