9 советов, как уговорить девушку. Точнее, как уговорить Заказчика работать по Agile, когда он этого не хочет

16.02.21

Управление проектом - Agile

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

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

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

24 февраля 2021 стартует Базовый курс  в рамках Комплексного курса  по управлению ИТ-проектами, а 25 марта - курс по Agile.  


Суть проблемы

Те, кто читали мою статью под заголовком “Как собрать исчерпывающие бизнес-функциональные требования в начале проекта внедрения?” помнят предлагаемый в ней ответ на поставленный в названии вопрос (спойлер: Никак!).

Действительно, практически всем кто имел опыт внедрения сколько-нибудь сложной информационной системы, знакома ситуация - наиболее полные и четкие требования бизнес-заказчики способны озвучить на финальных стадиях проекта, когда продукт пора переводить в опытно-промышленную эксплуатацию. А (конечно, если внедрение не “для галочки”, а систему предполагается использовать в реальной работе) предварительную версию ТЗ, созданную на старте, практически всегда приходится существенно трансформировать и дорабатывать.
Выход, разумеется, есть. Он описан, в частности, в моей статье Можно ли объять необъятное или чем Agile отличается от водопада? и предполагает использование вместо предиктивного подхода (“Водопада”) подходов адаптивных (итеративного, инкрементального или гибкого - Agile). Как известно, при работе по Agile мы не пытаемся создавать иллюзию, что ТЗ будет полным, и сразу констатируем тот факт, что окончательный объем, сроки и стоимость будут корректироваться по ходу. Для достижения главной цели - поставки бизнес-ценности, и получения продукта который будет максимально полезен Заказчику. В смысле, на самом деле максимально полезен, а не в том смысле, как он предполагал на начальных стадиях.  
Идея прекрасная, но бизнес-заказчик (особенно на внешних проектах) часто настаивает на том, чтобы исполнитель сразу описал объем работ, указал точные сроки и стоимость. 

Описание кейса 

Автор: Антон Солодков, РП, выпускник курсов по управлению ИТ-проектами.

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

1. Получили запрос на внедрение. Как-то примерно оценили общую стоимость исходя из допущений и опыта.
2. Сделали предпроектное обследование. Сформулировали этапы, описание, сроки, бюджет скорректировали (все что хотел видеть заказчик). При этом из заказчика как будто «клещами вытаскивали информацию». И почему-то устойчивое ощущение, что в проекте нас ждет огромное количество подводных камней, много решений/предложений, когда «ходим по краю» - один маленький шаг в сторону и вся архитектура «к чертям». На этом месте у Исполнителя сложилось устойчивое убеждение, что выполнить проект можно только гибкими методологиями - внедряя по частям, и уточняя требования по мере продвижения. 
3. У заказчика нет человека кто бы был «в теме» гибких методологий. При этом гибкие методологии предполагают активное участие заказчика во всем процессе разработки, следование общим принципам и методам командной работы (для успеха проекта необходимо тесное сотрудничество - фактически, общая команда исполнителя и заказчика). Конечно, можно было бы обучить заказчика гибким методологиям, но как это в реальности осуществить совершенно непонятно – никто не хочет время «тратить», тем более, что заказчик считает, что “итак все понятно”. 
4. В условиях высокой неопределенности определить бюджет проекта не представляется возможным. Просто умножить сумму «на 2» или «на 10» - вряд ли помогут. Во-первых есть конкуренты. А во-вторых, сколько не закладывай, если нет четкого понимания как управлять – все проестся и все-равно не хватит.
5.  Мария Темчина любит цитировать на этом месте афоризм:

- Ты сильный, ты справишься!
- Я умный, я даже не возьмусь!

Это, конечно, хороший ответ. Но часто именно изначально кажущиеся неразрешимые проекты давали бесценный опыт и были потом не просто рентабельны, но и выводили исполнителя на другой уровень развития. Хотелось бы возможных решений, как можно склонить Заказчика к Agiel?

Вопрос: как такие проекты запускать, как общаться с Заказчиком, на какие точки давить. Как донести другой порядок работы?

 

Как проходил мозговой штурм

 


Обсудить этот вопрос мы пригласили всех заинтересованных сторон (из сообщества Инфостарта, сообществ РП 1С, выпускников и слушателей курсов и т. п.).
На вебинаре собралось около 100 человек, причем большинство с многолетним опытом (на этой картинке можно посмотреть, кто из участников как оценил свой уровень профессионализма)...

 

 

 


И на онлайн-доске Miro мы попробовали разделиться на несколько команд и провести письменный мозговой штурм - BrainWriting. Кстати, очень рекомендую эту форму - мы часто его практикуем в Agile-команде разработчиков. В отличие от обычного мозгового штурма, когда каждый пытается выкрикнуть как можно больше идей и не всегда прислушивается к мнению других, письменное обсуждение более основательное. Во-первых, стирается преимущество между активными и разговорчивыми участниками и молчаливыми задумчивыми - писать готовы даже те, кто не любит громко говорить. Во-вторых, формат проведения мозгового штурма предполагает, что каждый высказывает одну свою идею, а потом по-очереди знакомится с идеями коллег и пытается придумать, как их идеи можно развить и продолжить. Ну и за счет того, что несколько участников по-очереди развивают и продолжают одну и ту же мысль, получается диалог вместо серии монологов. 
Если вы работаете на доске Miro, то там для обсуждения существует удобный шаблон BrainWriting. На первом шаге каждый из участников выбирает свой цвет, и записывает на первом стикере свою идею по рассматриваемому вопросу. Когда все записали идеи, участник перемещается в соседний столбец, читает идею своего коллеги и размышляет, как ее можно развить, продолжить, доработать, улучшить. И в следующей строчке на стикере своего цвета записывает свои мысли. В следующий ход участники опять перемещаются в следующий столбец, и теперь вслед уже за двумя коллегами развивают следующую идею…   А в конце автор каждой идеи смотрит вниз столбца, который он начал. И видит, куда идею развили и направили коллеги. Дальше можно выбирать наиболее конструктивные идеи, и можно обсуждать, как их можно применить на практике.

 

 


Советы, как уговорить Заказчика

Итак, какие же предложения прозвучали? Какие ходы и аргументы могут помочь “склонить заказчика к гибким методологиям” - то есть к работе “по кусочкам” с постепенным сбором требований и небольшими поставками?
Ниже привожу прозвучавшие идеи с моими комментариями

Совет №1. Познакомить с чужим опытом

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


Совет №2. Лучше один раз попробовать, чем сто раз услышать

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

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

1. Сначала он ставит задачу (или тот, кто по его мнению в курсе - руководитель среднего звена)

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


Совет №3. Обеспечить прозрачность


Тот факт, что заказчики часто “в штыки” воспринимают разговоры про возможный разброс в цене связано в первую очередь с недоверием. Поэтому важно не брать цифры с потолка, а показать прозрачный расчет вилки с учетом возможных рисков, влияющих на реализацию проекта. Чтобы было понятно, откуда взялись те или иные цифры.
Стоит внедрить систему управления проектами, например, Jira. И дальше предложить Заказчику контролировать стадии выполнения проекта в системе. Когда разработка из “черного ящика” превращается в понятный и управляемый процесс, вопросов и претензий становится резко меньше (ну, или они становятся более обоснованными).

 

Совет №4. Объяснить Заказчику, что Agile не увеличивает его риски, а наоборот, снижает

Очень часто страх применять гибкие методы обусловлен ощущением, что это более рискованно. Мол, при внедрении по Водопаду сразу понятен и план, и бюджет, и сроки поставки. А как работать, когда неизвестно в какую сумму внедрение выльется и сколько времени займет. Так вот, ключевая задача при взаимодействии - наглядно объяснить заказчику, что кажущаяся определенность “Водопада” - это иллюзия.
Скажем, добавляя этап моделирования можно в красках расписать Заказчику, что они смогут сразу же попробовать модель в работе. Ну и сразу будет понятно, какие требования сформулированы в формате “я думал будет хорошо, а вышло не очень…”
А при работе по водопаду Заказчику придется утвердить ТЗ на 300-500 страницах и потом все риски на его стороне. Ну а качественно собрать все требования в начале проекта, как мы помним, практически нереально...
Ну и если бюджет больная тема - то можно и на нее надавить, объяснив, что Agile - это еще и способ сэкономить. Стоит заранее объяснить, что в классическом подходе стоимость изменений в конце проекта, как правило, стоит дорого. Так что Agile - это способ сэкономить на ненужных переделках, но получить при этом нужный и ценный результат.
Стоит объяснить, что прототип поможет быстро реагировать на изменения требований и окружение бизнеса. И Цена изменения будет во много раз меньше, чем когда мы 3 месяца проектируем, потом 3-4 месяца настраиваем, а потом уже только получаем результат. Если прототип делается за месяц, то экономия составит почти 6-8 месяцев.

 

Совет №5. Перейти от общих слов к конкретике. Самый сложный шаг - первый. Выбираем самое важное 

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

 

Совет №6. Грамотно расставить акценты - не на недостатках, а на достоинствах

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

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

 

Совет №7. Ищите человека, который станет проводником изменений

Вполне возможно, что в культуре организации заказчика пока не говорят про гибкие технологии. Если убедить всех ключевых участников невозможно -попробуйте представителя руководства у Заказчика влияющего на проект и попытайтесь объяснить ему преимущества работы по гибким методологиям. 
Найти одного человека, через которого можно “протащить” изменения всегда проще, чем изменить культуру организации в целом.  Чтобы работа по Agile “взлетела” - важно найти людей "зажигалок", с активной позицией для уточнения ТЗ и примерной общей оценки, для выдачи более точных рамок разбега. А еще важно найти союзников из управленцев среднего звена - тогда работу удастся реально запустить, и даже есть шанс, что люди будут реально пользоваться продуктом.
Можно предлагать бизнес-заказчику почитать книжку по Scrum - говорят, с некоторыми заказчиками это срабатывает ))). Можно вообще подарить набор книг по управлению проектами при начале работы по проекту. 
Можно использовать человеческое любопытство и попробовать уговорить на эксперимент. Мол, для Заказчика это тоже интересный опыт работы “гибкими” методами, который потом можно применить в других сферах. Agile часто вызывает любопытство у тех, кто его не пробовал, ну и отличный повод освоить новую технологию!
Как известно - вода камень точит. Важно постепенно выстроить доверительные отношения с заказчиком. Начинать совместную работу стоит с небольших задач или проектов, а дальше постепенно все уже “притираются” друг к другу. При этом важно показывать свою компетентность - она повышает доверие.
Кстати, иногда стоит избегать слова Agile
Бывают компании, где “гибкие методологии” - слово ругательное (чаще всего по итогам негативного опыта из серии “мы не документируем, у нас Agile”). В такой ситуации можно подробно объяснить, что имеется в виду по сути - например, что мы предлагаем часто встречаться для сверки и корректировки результата. И преподнести метод "под другим соусом". Иногда этого бывает достаточно, чтобы предложение сработало.

 

Совет №8. Использовать разные методы создания определенности в сфере расходов 

Время и материалы. Один из способов добавить определенности в расходы - это перейти на контракт “Время и материалы”. То есть оговориться, что исполнитель выполняет каждый месяц фиксированный объем работ за фиксированную оплату. А очередь заданий как раз можно сделать динамической - то есть изменяемой под текущие запросы/приоритеты. Что важно - динамическая очередь должна оперативно формироваться, редактироваться и быть доступной клиенту онлайн в режиме реального времени 
Кстати, можно еще и проговорить, что при уточнении требований задачи будут не только добавляться - . часть ТЗ, возможно, уйдет. Соответственно бюджет будет потрачен более целенаправленно.

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

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


Совет №9. Оговорить в договоре возможность пересмотра параметров проекта при желании обеих сторон

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

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

 

Ну и для тех, кто дочитал статью до конца - еще одно приглашение на курсы по управлению проектами - с актуальным расписанием можно познакомиться на странице курсов Марии Темчиной
Кстати, нулевой Welcome-вебинар 24 февраля по традиции будет открытым - присоединяйтесь, продолжим практику мозговых штурмов!.. 

См. также

Agile Бесплатно (free)

В статье рассмотрены практики, применяемые при разработке по методологии Agile.

13.05.2024    3562    0    Dimbayyyy    9    

11

Лидерство Личная эффективность Agile Анализ потребностей и поиск решений Бесплатно (free)

В семнадцатом выпуске второго сезона подкаста Радио “Аналитик“ обсудили, что из себя представляет модель Кеневин, чем и в каких ситуациях она может быть полезна тем, кто работает в сфере ИТ и не только.

19.04.2024    622    0    Radio_Analyst    0    

5

Agile Бесплатно (free)

Agile в ИТ встречается все чаще, и об адаптации гибких технологий под проекты 1С задумываются многие. Расскажем о ключевых инструментах и точках приложения усилий для успешного внедрения Scrum при разработке в 1С.

28.07.2023    2533    0    olegminkov    4    

7

Agile Руководитель проекта Россия Бесплатно (free)

Продукт команды №7, 6 поток (курс Марии Темчиной «Управление ИТ-проектами. Agile. Практический курс Agile-лидера»)

13.06.2023    1502    8    dimbasbear    1    

2

Agile Бесплатно (free)

На конференции Infostart Event 2021 Post-Apocalypse выступил директор практики БИТ:ERP компании Первый БИТ Глеб Стальной. В ходе доклада он рассмотрел трансформацию проектного подхода в продуктовый, рассказал про имплементацию «современных» практик DevOps и продемонстрировал инструменты для разработки, взаимодействия с бизнесом и клиентами, применяемые в его команде.

27.02.2023    2565    0    glebushka    2    

14

Agile Бизнес-аналитик Руководитель проекта Бесплатно (free)

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

06.12.2021    4326    0    MariaTemchina    49    

13

Agile Бесплатно (free)

Есть сообщество в Facebook'е и Инстаграм, которое публикует жизненные комиксы про внедрение гибких технологий на практике - Comic Agile.

01.04.2021    3880    0    MariaTemchina    18    

16

Agile Руководитель проекта Бесплатно (free)

Коллеги, приглашаем поучаствовать в опросе - Agile в проектах внедрения 1С: реально работает или это миф? Интересен практический опыт!..

12.03.2021    8484    0    MariaTemchina    86    

27
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. пользователь 16.02.21 14:24
Сообщение было скрыто модератором.
...
2. DitriX 2098 16.02.21 15:11 Сейчас в теме
Вопрос - какие технологии для развертывания и тестирования вы используете на проекте? Отсюда можно сделать вывод - верить вашей статье или нет :)
15. MariaTemchina 1614 17.02.21 14:09 Сейчас в теме
(2) Дмитрий, еще раз уточняю - данная конкретная статья представляет итоги группового обсуждения. То есть вопрос про технологии надо задавать каждому участнику по-отдельности...
3. user670659_lms.buch 16.02.21 16:58 Сейчас в теме
Огласите пожалуйста список проектов где это применялось.
16. MariaTemchina 1614 17.02.21 14:10 Сейчас в теме
(3) Еще раз уточняю - данная конкретная статья представляет итоги группового обсуждения. То есть это вопрос ко всем участникам...
20. Yashazz 4762 17.02.21 22:11 Сейчас в теме
(3) Не ждите. Список проектов нам никто не огласит. Будут увиливать, выкручиваться, жонглировать умными словами, прикрываться конфиденциальностью и хз чем ещё... А суть проста - успешных проектов нету. Есть случаи успешного отъёма денег у лопухов, это да. Но о них тоже рассказывать не станут)

Как мне однажды один, простихосспади, ДевОпс-евангелист (пардон за нецензурщину) признался в порыве душевного откровения: "да фигня это всё, на практике не более 25-30% вообще воплотимо, и то буквально раз было за 10 лет". Вот примерно так и все эти аджайл-адепты.
27. papami 56 18.02.21 12:41 Сейчас в теме
(20)
на практике не более 25-30% вообще воплотимо, и то буквально раз было за 10 лет"

Думаю, чем выше фактическая квалификация команды, тем больше вероятность успешной реализации проекта. Т.е., на деле, вопрос подхода к управлению проектом может и играет роль, но не такую значительную как принято считать.
29. MariaTemchina 1614 18.02.21 14:45 Сейчас в теме
(20) Кстати, в том что касается DevOps в 1С я с вами, как это не удивительно, соглашусь. Нечасто бывает воплотимо и целесообразно. Хотя подвижки в этом направлении идут. А в других ИТ-сферах ситуация выглядит не так.

ДевОпс-евангелист (пардон за нецензурщину) признался в порыве душевного откровения: "да фигня это всё, на практике не более 25-30% вообще воплотимо, и то буквально раз было за 10 лет"
4. booksfill 16.02.21 18:20 Сейчас в теме
Хотелось бы понять, когда именно принимается решение об архитектуре проекта, и насколько подробно?

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

Пример: решили строить одноэтажный дом, потом "ну, пока крышу не сделали, пристроить еще пару этажей" и сделать подземный гараж = полностью снести дом + заплатить за вывоз мусора + переделать септик + согласовать постройку снова + и т.п. И все это уже по возросшим ценам и с потерей времени.

Может процесс непрерывных улучшений более приспособлен для развития уже работающего функционала, или не критичных изменений в ходе нового проекта? Никто не будет строить завод Тойота по гибкой технологии, а вот потом, наоборот, идет непрерывное совершенствование. Или... есть примеры, на крупных проектах, а не стартапах?
FatPanzer; +1 Ответить
6. RustIG 1720 17.02.21 00:30 Сейчас в теме
(4)
Хотелось бы понять, когда именно принимается решение об архитектуре проекта, и насколько подробно?

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

кто-то потеряет деньги, но приобретет опыт - либо внедренец из-за своей недальновидности, либо Заказчик из-за своей некомпетентности.
17. dkoder 5 17.02.21 19:46 Сейчас в теме
(6)наоборот заказчик из-за своей недальновидности, что нанял не специалистов. внедренец из-за своей некопетентности. "гибкие" технологии лучший способ скрыть некомпетентность исполнителя. И почему такой скудный выбор agile или каскадные - плохо себя ограничивать
30. MariaTemchina 1614 18.02.21 14:47 Сейчас в теме
(4) Сергей, мне близка точка зрения, что Agile не очень подходит для проектов со сложной архитектурой.
Ну и добавлю, что история, когда решили построить одноэтажный дом, потом пристроить и т. п. бывает и при управлении по "Водопаду" сплошь и рядом :-(((.
Очень часто при Agile, наоборот, быстрее понимают, что фигня получается, и всё сносят. То есть затраты на неудачный эксперимент оказываются ниже.
33. booksfill 18.02.21 18:32 Сейчас в теме
(30)
Полагаю, что сперва надо поставить конкретные, измеримые цели на уровне архитектуры системы, комплексно.
Например, уменьшение товарных запасов на складах на столько-то процентов в стоимостном и количественном выражении.
Причем никаких: "Давайте внедрим этот критичный блок, а потом нам, конечно много еще чего понадобится. но давайте сделаем вид, что мы про это забыли".

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

Дальнейшая конкретизация ТЗ имеет смысл только для сильно детерменированных задач, иначе это тормоз.

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

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

Иначе команда потратит средства и время собственника на удовлетворение амбиций работника (а в большинстве случаев на борьбу с итальянской забастовкой. Причем я про ту ее разновидность когда "вроде хочется, но это мне. что, еще думать надо?"
5. RustIG 1720 17.02.21 00:22 Сейчас в теме
мое имхо.
- про финансы -
любая компания живет бюджетами (фондами) - из года в год - закладываются бюджеты на разное - в том числе на запуск и внедрение Айти, сопровождение Айти и т.д.

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

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

Хорошо, если финансовый учет поставлен и вам сразу скажут, сколько запланировано на этот год конкретно на ваше 1с-направление. А если нет?

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

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

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

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

что-то навязывать заранее этому менеджеру бессмысленно, пока он месяц не поработает в программе, а слушать будут как раз его мнение на совещании, а не ваше...
Yashazz; Климов Сергей; itriot11; MariaTemchina; CodeNull; lepth; Артано; +7 Ответить
31. MariaTemchina 1614 18.02.21 14:49 Сейчас в теме
(5)
Рустем, часто такой метод оказывается действенным. Существенный недостаток у него следующий: незамотивированные сотрудники по итогам такой тестовой эксплуатации могут заявить, что "все плохо" и "эту бяку они использовать никогда не будут"... И до следующего этапа - допиливания до удобного формата - можно уже и не дойти...
я сторонник такого подхода - дать программу Заказчику в том виде, в котором она уже реализована, провести обучение типовым функциям - выделенный ответственный менеджер через месяц вам сам скажет, что ему не хватает, что не устраивает, за что он готов заплатить деньги...
7. CheBurator 3126 17.02.21 04:36 Сейчас в теме
"Совет №1. Познакомить с чужим опытом"
- вряд ли. Чужой опыт - это НЕ МОЙ опыт успешного аджайла.
а когда нет успешных собственных проектов с аджайлом - как начать ПЕРВЫЙ? - совет1 - мимо...
smit1c; FatPanzer; +2 Ответить
14. MariaTemchina 1614 17.02.21 14:04 Сейчас в теме
(7) Здесь можно воспользоваться особенностью человеческой психики, что мы склонны себя идентифицировать с другими и сопереживать. Если подробно и правдоподобно описать контекст ситуации, собеседник узнает знакомые проблемы - то рассказанная история может повысить доверие. Может помочь диалогу. Может и не помочь, конечно - здесь универсальные советы вообще трудно дать. Как и с девушками.
18. CheBurator 3126 17.02.21 20:13 Сейчас в теме
(14)
Может помочь диалогу. Может и не помочь, конечно - здесь универсальные советы вообще трудно дать.

- ну так и следует писать: рецептов нет, каждый сам кузнец своего фломастера.
19. Yashazz 4762 17.02.21 22:08 Сейчас в теме
(18) Естессно нет. Все эти "гуру", "евангелисты" и прочие проповедники - пустопорожние трепачи, которые умело пускают пыль в глаза руководству своими общими словами, за которыми никакой конкретики. Ждать от них предметных полезных советов бессмысленно.
28. oleynikovpm 18.02.21 14:35 Сейчас в теме
(7)Как ты ходить научился, у тебя же не было СВОЕГО опыта хождения на двух ногах?
34. CheBurator 3126 19.02.21 13:59 Сейчас в теме
(28) меня родители учили. поддерживали чтобы не падал. забесплатно. причем даже еще алфавита я не знал.
если кто возьмет меня ничего не умеющего безграмотного в аджайл проект и поучит меня забесплатно...
35. dklimchuk 44 19.02.21 14:06 Сейчас в теме
(34)т.е. директивно, против твоей воли, но с любовью и заботой. Т.е. заботливо пнули "давай учись". Ползать, ходить, бегать, прыгать, марафоны, с препятствиями и т.п. - в порядке усложнения. И это нормально. А чем принципиально это обучение от родителей отличается от обучения какому-то навыку? Например аджайлу? Да даже если тут и сейчас кажется, что в нем, этом аджайле, смысла нет? Мария, конечно, не мама, но она умеет научить. Таки почему нет?
37. CheBurator 3126 19.02.21 19:28 Сейчас в теме
(35) Мария нехай аджайлу заказчиков учит. как только Заказчики будут массово готовы работать по аджайлу - так технари без проблем подстроятся.
36. oleynikovpm 19.02.21 16:26 Сейчас в теме
(34) А лучше, чтобы взяли в аджайл проект, обучали и платили )))
CheBurator; dklimchuk; +2 Ответить
8. Dragonim 140 17.02.21 09:56 Сейчас в теме
Вот как я вижу Agile:

Хороший 1С программист готов разрабатывать любой ваш функционал по вашему требованию. Техническое задание не требуется. Вы всегда можете поставить новую задачу, отменить или изменить существующую. Всё для вас. Работаю по предоплате. Дорого.
Ta_Da; papami; roman72; Cерый; CodeNull; Yashazz; CheBurator; MariaTemchina; BomjBandit; +9 Ответить
13. MariaTemchina 1614 17.02.21 14:02 Сейчас в теме
(8) Похоже, да. Только по моим представляениям примерно представление об архитектуре продукта должно быть. И примерная дорожная карта. Иначе не Agile, а тяп-ляп получается.
26. Yashazz 4762 18.02.21 11:24 Сейчас в теме
(8) Вот. Браво. Вся эта показушная заумь утрамбовывается в вашу реплику.

Но, поскольку не все хотят идти мешки ворочать, трындёж имеет место быть с неимоверными понтами.
9. Nubsdale 17.02.21 13:23 Сейчас в теме
На вебинаре собралось около 100 человек, причем большинство с многолетним опытом (на этой картинке можно посмотреть, кто из участников как оценил свой уровень профессионализма)...

На картинке 52 маленьких круга, 2 маленьких квадрата и 1 большой квадрат. Где остальные 45 человек? :))
11. MariaTemchina 1614 17.02.21 14:00 Сейчас в теме
(9) 100 человек дошли до Зума и участвовали там, но, видимо, 45 из них поленились делать упражнение... )))

Так обычно и бывает - напоминает воронку продаж: человек 200 записалось, из них 100 дошло, 60 начали делать упражнения, 40 закончили...
dklimchuk; Nubsdale; +2 Ответить
21. Yashazz 4762 17.02.21 22:17 Сейчас в теме
(11) А потому что, к счастью, люди не совсем слепоглухонемые и начинают понимать, что "кажется, это какая-то фигня" (с). Вы хоть один раз своё конкретное достижение опубликуйте да подробно разберите, тогда, может, серьёзные и толковые люди заинтересуются. А изучать видеокурс в духе "как нам вдохновенно трындеть об умных материях" - это, видите ли, интересно тем, кому нравится трындежом зарабатывать... Как-то так.
22. klimdw 17.02.21 22:22 Сейчас в теме
(21)а у вас есть подобные достижения? Покажите, как надо, плз
black_wizard; +1 Ответить
23. Yashazz 4762 18.02.21 08:49 Сейчас в теме
(22) А я не трепач, я делом занимаюсь. И если вы умеете пользоваться поиском, то сами найдёте конкретные достижения, например, среди моих публикаций. И не переводите разговор - прием "покажи сам, как надо" это примитивненько)
24. klimdw 18.02.21 08:59 Сейчас в теме
(23) :))
Не ждите. Список проектов нам никто не огласит. Будут увиливать, выкручиваться, жонглировать умными словами, прикрываться конфиденциальностью и хз чем ещё...

Я делом занимаюсь - это да. это прям аргументище.
black_wizard; itriot11; RustIG; +3 Ответить
25. Yashazz 4762 18.02.21 11:22 Сейчас в теме
(24) Сам-то по делу скажешь что, аль нечего сказать?) Защитничек?))

Коллеги, видите реакцию, да? Перевод стрелок, эдакое бессильное барахтание... Потому что нечего им всем сказать по сути-то. Мыльный пузырь, надувание щёк, ничего более.
user1270271; +1 1 Ответить
32. MariaTemchina 1614 18.02.21 14:51 Сейчас в теме
(21) Спасибо за рекомендации, что именно мне нужно публиковать и кого мне нужно заинтересовывать!
Обязательно приму во внимание.
black_wizard; klimdw; +2 Ответить
10. morin 59 17.02.21 13:48 Сейчас в теме
Так девушку вы не уговорите.
12. MariaTemchina 1614 17.02.21 14:00 Сейчас в теме
(10) Смотря какая девушка...
39. black_wizard 20.02.21 21:12 Сейчас в теме
(12) Мария, терпения Вам, мат тут запрещен, потому сказать большего про диспут не могу :)
38. ManyakRus 485 20.02.21 11:23 Сейчас в теме
"Водопад" имеет конечную стоимость, или хотя бы максимальную стоимость.
Agile - имеет бесконечную стоимость, и бесконечную работу.
Как вы уговорите потратить вместо 1 млн. руб - бесконечно млн. руб ?
41. Ndochp 103 22.05.21 19:23 Сейчас в теме
(38) Водопад кроме конечной стоимости имеет еще и низкую вероятность попадания (и нигде не используется не то что давно - никогда).
А итеративный водопад имеет тоже бесконечную стоимость и работу (на первый взгляд).
По факту - там бесконечность та же, что и в апории про Ахилеса и черепаху.
Вот тут математика для скрама
https://mnogosdelal.ru/slidecasts/project-estimation/#page-content
42. ManyakRus 485 24.05.21 09:25 Сейчас в теме
(41) Для бесконечной работы нужны штатные сотрудники, а не посторонние организации с методологией бесконечной работы Agile. Сторонние организации нужны для выполнения временной определённой задачи, стоимость которой надо знать заранее.
43. Ndochp 103 27.05.21 17:58 Сейчас в теме
(42) Сейчас в любом PMBoKе, даже редакции две назад пишут про итеративные проекты. Причем практически про все проекты как итеративные. А итеративные = бесконечные. Так как договариваются о первом шаге, но имеют понимание, что шагов будет много.
Просто итеративный водопад это квартал-полгода на итерацию, а итеративный эджайл - неделя-две.
Так что в эджайле ты как заказчик деньгами даже меньше рискуешь: можешь выгнать всех после очередной пятничной демки и поиметь пользу.
44. ManyakRus 485 28.05.21 10:03 Сейчас в теме
(43) Штатный сотрудник ещё лучше - каждая задача будет полностью готова и протестирована через 1-2 дня а не через 1-2 недели :)
45. Ndochp 103 29.05.21 00:48 Сейчас в теме
(44) Большой вопрос, потеряете вы больше денег закрыв работы с фрилансером в эту пятницу или предупредив сотрудника, что через месяц он получит 2 оклада и сможет быть свободен.
(не забудьте закрыть позицию в штатке и не нанимать на неё никого полгода)
46. ManyakRus 485 31.05.21 13:02 Сейчас в теме
(45) Фрилансеру надо платить в 2-3 раза больше чем штатному сотруднику, поэтому отдать 2 оклада выгоднее.
А вообще главное не деньги а результат. Гарантия что штатный сотрудник сделает проект за хотя бы бесконечное время: 99%. Гарантия что посторонняя организация сделает для вас всё что надо за бесконечное время (не бесконечные деньги): 10%-50%
40. mephistofel 16 06.03.21 14:04 Сейчас в теме
Для случая проекта внедрения решения на платформе 1С заказчик не хочет пользоваться гибкими методами управления проектом, потому что не хочет оставлять за собой риск того, что он не получит результат проекта из-за того, что деньги закончились. Поэтому заказчик хочет услышать от исполнителя цену, за которую заказчик точно получит результат проекта. Для себя подразумевая, что после того, как цена озвучена риск неполучения результата за озвученную цену оказывается на стороне исполнителя. И по другому заказчик не согласится. Потому что смотри первое предложение.
Отсюда видится направление решения проблемы. К гибким методам управления проектом нужны гибкий метод определения стоимости проекта и гибкий метод управления стоимостью проекта.
Оставьте свое сообщение