15 шагов к быстрым сделкам на тендерных площадкахConformato
Анастасия Новикова на Conformato Conference 2014 рассказывала о быстрых сделках 15 апреля, а 17 - продолжала свой доклад по многочисленным просьбам.
Доклад на тему "15 шагов к быстрым сделкам на тендерных площадках" содержит алгоритм, который эффективно работает и указывает на типичные ошибки.
Помимо этого Анастасия сразу же предлагает пути их решения.
=Чтобы посмотреть видеозапись доклада, зарегистрируйтесь здесь: http://goo.gl/uK0rmY =
Василий Чепцов, PMBOK для Agile-менеджера. Чем полезен?ScrumTrek
В Agile-сообществе можно встретить немало мифов и поверхностных суждений о подходах к управлению, где не используется слово "Agile". Больше всех, пожалуй, "досталось" методологии управления проектами PMI PMBOK... "Водопад", Гант, куча документации — это же всё ужасно с точки зрения Agile! Недавно мне пришлось хорошенько проштудировать PMBOK (для подготовки к экзамену) и теперь по горячим следам хочется вдумчиво обсудить: — какие популярные суждения о PMBOK верны, а какие нет? — как же всё-таки соотносятся эти подходы? — и, главное, чем нам PMBOK может быть полезен в Agile-разработке?
15 шагов к быстрым сделкам на тендерных площадкахConformato
Анастасия Новикова на Conformato Conference 2014 рассказывала о быстрых сделках 15 апреля, а 17 - продолжала свой доклад по многочисленным просьбам.
Доклад на тему "15 шагов к быстрым сделкам на тендерных площадках" содержит алгоритм, который эффективно работает и указывает на типичные ошибки.
Помимо этого Анастасия сразу же предлагает пути их решения.
=Чтобы посмотреть видеозапись доклада, зарегистрируйтесь здесь: http://goo.gl/uK0rmY =
Василий Чепцов, PMBOK для Agile-менеджера. Чем полезен?ScrumTrek
В Agile-сообществе можно встретить немало мифов и поверхностных суждений о подходах к управлению, где не используется слово "Agile". Больше всех, пожалуй, "досталось" методологии управления проектами PMI PMBOK... "Водопад", Гант, куча документации — это же всё ужасно с точки зрения Agile! Недавно мне пришлось хорошенько проштудировать PMBOK (для подготовки к экзамену) и теперь по горячим следам хочется вдумчиво обсудить: — какие популярные суждения о PMBOK верны, а какие нет? — как же всё-таки соотносятся эти подходы? — и, главное, чем нам PMBOK может быть полезен в Agile-разработке?
Post Agile эра / Борис Вольфсон (HeadHunter)Ontico
Многие компании успешно используют Agile-методологии на протяжении многих лет. На данный момент некоторые из них переосмысливают понимание Agile, распространяя его за пределы конкретных методологий.
Я расскажу о том, как сделать компанию / подразделение по-настоящему гибкими, выстроив собственный Agile-фреймворк. Для создания такого фреймворка нужно понимать, из чего он состоит: от методологии управления проектами до организационной культуры.
Если вы уже успешно используете Scrum или Kanban и задумываетесь о том, что вам необходимо делать дальше - добро пожаловать на мой доклад!
Владимир Стасевич, Сбербанк и Agile – понятия совместимыеScrumTrek
В моем выступлении мы по шагам пройдем наш тернистый путь к продукту Сбербанк Онлайн, каким мы знаем его сегодня. С момента первого запуска нашего мобильного приложения мы преодолели огромное расстояние – как внутри команды, так и внутри такой огромной структуры, как Сбербанк.
Я буду в деталях рассказывать о том, какие методы мы внедряли, с какими проблемами сталкивались, как строили культуру, как формировали доверие в команде и в каком виде сейчас у нас работает Agile.
Участникам конференции наш кейс будет особенно интересен тем, что речь пойдет не столько об IT, сколько о создании продукта. Я подробно расскажу о формировании цикла product discovery – сложной, крупной задаче, под которую мы подбирали свои методы. В процессе мы столкнулись с разными трудностями, а еще активно работали над созданием культуры и среды, которая бы стимулировала креатив и генерацию идей внутри команды. В докладе не будет воды и голословных тезисов – только реальные примеры, только работающие методы, только хардкор.
User Stories - этот подход к описанию знаний о продукте просто понять и очень сложно использовать :) Кроме того, складывается ощущение, что при его использовании забывается самая главная часть - умение рассказывать истории о продукте и формировать общее понимание без необходимости подробного описания всех спецификаций, которые все равно никто никогда не читает. Мы постарались собрать все темы, которые необходимо осветить для беспрепятственной реализации задумок и разработали специальный инструмент для фасилитации обсуждений - User Story Canvas
Андрій Уманський: Роль розробника в продуктовій компанії. Product engineer – ...Lviv Startup Club
Kyiv Project Management Day 2016 Андрій Уманський: Роль розробника в продуктовій компанії. Product engineer – швидше, краще, дешевше
Сайт конференції: http://pmday.org/
Спільнота в мережі Linkedin: http://bit.ly/PMDayLin
Спільнота в мережі facebook: http://bit.ly/PMDayKyivFB
Twitter конференції: https://twitter.com/LvivPMDay
Иван Дубровин, Возможные подходы к контрактованию в AgileScrumTrek
Сравнительный анализ моделей заключения контрактов на Agile-разработку ПО: -"Традиционный" fixed-price и fixed-scope -Time materail -Agile fixed-price плюсы и минусы каждого варианта, рекомендуемый подход к составлению Agile fixed-price контракта.
Владимир Завертайлов. Выравнивание нагрузки в IT-компании: впихнуть невпихуемое.ScrumTrek
Доклад нацелен на подготовленных слушателей, руководителей проектов или директоров студий с десятком и более сотрудников, в общих чертах что-то слышавших про LEAN и ТОС. Выстройте поток единичных изделий, выравнивайте его и оптимизируйте скорость — говорит нам LEAN и производственная система Тойоты. Найдите ограничение и подчините ритму его работы все остальные звенья производственной цепи, Сбалансировать поток невозможно, говорит нам теория ограничений (ТОС). Все это очевидно работает, в примерах производства серийной продукции. Но и то и другое непонятно как применить на практике в сфере услуг. Тем более таких высоко кастомизируемых, как наша сфера — digital. Нам, директорам, больно смотреть, когда штатный сотрудник остаётся без задач, т.к. не готовы или не согласованы работы предыдущего этапа. Мы стремимся загрузить всех и максимально. Порой это приводит к тому, что мы хватаемся за огромное число проектов. А вдруг какой-то застрянет на согласовании — такой логикой руководствуемся мы. Это приводит либо к большим очередям (клиенты вынуждены ждать и ненавидеть it-шников за неповоротливость). Либо к необходимости перегружать сотрудников, а это приводит к повышенному проценту брака в их работе, и, как следствие, к дополнительной перегрузке, низкой скорости и ненависти к it-шникам со стороны клиента. Впихнуть невпихуемое и не стать студией, где считается преступлением быть «не затраханным». В этом докладе мы разберемся с вами, что можно автоматизировать для балансировки нагрузки. Что можно выбрать за единичное изделие. Как построить поток, визуализировать его, найти узкое звено и научиться предсказывать, где и когда у вас в
Дарья Рыжкова. Прекратите искать и начните предпринимать! Или почему традицио...ScrumTrek
В условиях современной экономики и быстро изменяющегося мира компании все чаще задумываются о поиске новых точек роста или дополнительных возможностей для дальнейшего масштабирования бизнеса. А для того, чтобы их найти, прибегают к помощи маркетинговых исследований. Результатами их становятся красивые презентации, объемные документы, обещающие новые возможности, которые как правило оседают мертвым грузом на полках архивов. В digital сегменте все еще печальнее: можно пойти в направлении, которое было найдено, но потерпеть сокрушительную неудачу.
Современная реальность такова: компании могут самостоятельно без посредников находить новые точки роста, используя свою экспертизу и многолетний опыт. Чтобы это произошло, необходимо научиться применять новые подходы и формировать новую культуру внутри организации, нацеленную на корпоративное предпринимательство. Как это сделать, почему старые подходы к исследованию рынка не работают и что приходит им на смену — об этом бы мне и хотелось поговорить.
Давайте прекратим исследовать и начнем предпринимать!
Максим Цепков, Agile - то что на самом деле нужно гос.заказчикам!ScrumTrek
Многие доклады про использование гибких методологий разработки в проектах с государственным заказчиком рассказывают о том, как изолировать команду от заказчика для обеспечения Agile-процесса. Но нужно ли это на самом деле?
Ведь для заказчика, как правило, важно работающее программное обеспечение, а не документация на него, важно сотрудничество, а не контракты, важна готовность команды к изменениям — иными словами, те ценности, что декларирует Agile-манифест. Формальные требования воспринимаются заказчиком как дополнительная нагрузка на внутренние процессы, которые долго и сложно перестраивать. Поэтому секрет долгосрочного успешного сотрудничества — в грамотной адаптации деятельности компании-разработчика к условиям заказчика. За время доклада мы рассмотрим воплощение этого тезиса на конкретных примерах из опыта работы нашей компании с такими заказчиками, как Банк России, Газпромбанк и другими.
Как попасть в лучшие 5% при прохождении собеседования на удаленную работу в T...GoSharp
Почему TopTal берет только верхние 5%, кто это люди и какими качествами они обладают. По каким критериям проходит оценка .Net разработчика на техническом собеседовании и как к нему подготовиться.
Post Agile эра / Борис Вольфсон (HeadHunter)Ontico
Многие компании успешно используют Agile-методологии на протяжении многих лет. На данный момент некоторые из них переосмысливают понимание Agile, распространяя его за пределы конкретных методологий.
Я расскажу о том, как сделать компанию / подразделение по-настоящему гибкими, выстроив собственный Agile-фреймворк. Для создания такого фреймворка нужно понимать, из чего он состоит: от методологии управления проектами до организационной культуры.
Если вы уже успешно используете Scrum или Kanban и задумываетесь о том, что вам необходимо делать дальше - добро пожаловать на мой доклад!
Владимир Стасевич, Сбербанк и Agile – понятия совместимыеScrumTrek
В моем выступлении мы по шагам пройдем наш тернистый путь к продукту Сбербанк Онлайн, каким мы знаем его сегодня. С момента первого запуска нашего мобильного приложения мы преодолели огромное расстояние – как внутри команды, так и внутри такой огромной структуры, как Сбербанк.
Я буду в деталях рассказывать о том, какие методы мы внедряли, с какими проблемами сталкивались, как строили культуру, как формировали доверие в команде и в каком виде сейчас у нас работает Agile.
Участникам конференции наш кейс будет особенно интересен тем, что речь пойдет не столько об IT, сколько о создании продукта. Я подробно расскажу о формировании цикла product discovery – сложной, крупной задаче, под которую мы подбирали свои методы. В процессе мы столкнулись с разными трудностями, а еще активно работали над созданием культуры и среды, которая бы стимулировала креатив и генерацию идей внутри команды. В докладе не будет воды и голословных тезисов – только реальные примеры, только работающие методы, только хардкор.
User Stories - этот подход к описанию знаний о продукте просто понять и очень сложно использовать :) Кроме того, складывается ощущение, что при его использовании забывается самая главная часть - умение рассказывать истории о продукте и формировать общее понимание без необходимости подробного описания всех спецификаций, которые все равно никто никогда не читает. Мы постарались собрать все темы, которые необходимо осветить для беспрепятственной реализации задумок и разработали специальный инструмент для фасилитации обсуждений - User Story Canvas
Андрій Уманський: Роль розробника в продуктовій компанії. Product engineer – ...Lviv Startup Club
Kyiv Project Management Day 2016 Андрій Уманський: Роль розробника в продуктовій компанії. Product engineer – швидше, краще, дешевше
Сайт конференції: http://pmday.org/
Спільнота в мережі Linkedin: http://bit.ly/PMDayLin
Спільнота в мережі facebook: http://bit.ly/PMDayKyivFB
Twitter конференції: https://twitter.com/LvivPMDay
Иван Дубровин, Возможные подходы к контрактованию в AgileScrumTrek
Сравнительный анализ моделей заключения контрактов на Agile-разработку ПО: -"Традиционный" fixed-price и fixed-scope -Time materail -Agile fixed-price плюсы и минусы каждого варианта, рекомендуемый подход к составлению Agile fixed-price контракта.
Владимир Завертайлов. Выравнивание нагрузки в IT-компании: впихнуть невпихуемое.ScrumTrek
Доклад нацелен на подготовленных слушателей, руководителей проектов или директоров студий с десятком и более сотрудников, в общих чертах что-то слышавших про LEAN и ТОС. Выстройте поток единичных изделий, выравнивайте его и оптимизируйте скорость — говорит нам LEAN и производственная система Тойоты. Найдите ограничение и подчините ритму его работы все остальные звенья производственной цепи, Сбалансировать поток невозможно, говорит нам теория ограничений (ТОС). Все это очевидно работает, в примерах производства серийной продукции. Но и то и другое непонятно как применить на практике в сфере услуг. Тем более таких высоко кастомизируемых, как наша сфера — digital. Нам, директорам, больно смотреть, когда штатный сотрудник остаётся без задач, т.к. не готовы или не согласованы работы предыдущего этапа. Мы стремимся загрузить всех и максимально. Порой это приводит к тому, что мы хватаемся за огромное число проектов. А вдруг какой-то застрянет на согласовании — такой логикой руководствуемся мы. Это приводит либо к большим очередям (клиенты вынуждены ждать и ненавидеть it-шников за неповоротливость). Либо к необходимости перегружать сотрудников, а это приводит к повышенному проценту брака в их работе, и, как следствие, к дополнительной перегрузке, низкой скорости и ненависти к it-шникам со стороны клиента. Впихнуть невпихуемое и не стать студией, где считается преступлением быть «не затраханным». В этом докладе мы разберемся с вами, что можно автоматизировать для балансировки нагрузки. Что можно выбрать за единичное изделие. Как построить поток, визуализировать его, найти узкое звено и научиться предсказывать, где и когда у вас в
Дарья Рыжкова. Прекратите искать и начните предпринимать! Или почему традицио...ScrumTrek
В условиях современной экономики и быстро изменяющегося мира компании все чаще задумываются о поиске новых точек роста или дополнительных возможностей для дальнейшего масштабирования бизнеса. А для того, чтобы их найти, прибегают к помощи маркетинговых исследований. Результатами их становятся красивые презентации, объемные документы, обещающие новые возможности, которые как правило оседают мертвым грузом на полках архивов. В digital сегменте все еще печальнее: можно пойти в направлении, которое было найдено, но потерпеть сокрушительную неудачу.
Современная реальность такова: компании могут самостоятельно без посредников находить новые точки роста, используя свою экспертизу и многолетний опыт. Чтобы это произошло, необходимо научиться применять новые подходы и формировать новую культуру внутри организации, нацеленную на корпоративное предпринимательство. Как это сделать, почему старые подходы к исследованию рынка не работают и что приходит им на смену — об этом бы мне и хотелось поговорить.
Давайте прекратим исследовать и начнем предпринимать!
Максим Цепков, Agile - то что на самом деле нужно гос.заказчикам!ScrumTrek
Многие доклады про использование гибких методологий разработки в проектах с государственным заказчиком рассказывают о том, как изолировать команду от заказчика для обеспечения Agile-процесса. Но нужно ли это на самом деле?
Ведь для заказчика, как правило, важно работающее программное обеспечение, а не документация на него, важно сотрудничество, а не контракты, важна готовность команды к изменениям — иными словами, те ценности, что декларирует Agile-манифест. Формальные требования воспринимаются заказчиком как дополнительная нагрузка на внутренние процессы, которые долго и сложно перестраивать. Поэтому секрет долгосрочного успешного сотрудничества — в грамотной адаптации деятельности компании-разработчика к условиям заказчика. За время доклада мы рассмотрим воплощение этого тезиса на конкретных примерах из опыта работы нашей компании с такими заказчиками, как Банк России, Газпромбанк и другими.
Как попасть в лучшие 5% при прохождении собеседования на удаленную работу в T...GoSharp
Почему TopTal берет только верхние 5%, кто это люди и какими качествами они обладают. По каким критериям проходит оценка .Net разработчика на техническом собеседовании и как к нему подготовиться.
Как попасть в лучшие 5% при прохождении собеседования на удаленную работу в T...geekfamilyrussia
Почему TopTal берет только верхние 5%, кто это люди и какими качествами они обладают. По каким критериям проходит оценка .Net разработчика на техническом собеседовании и как к нему подготовиться.
5 правил успешной разработки приложений для бренда Heads&Hands
Презентация о правилах разработки мобильных приложений для крупных брендов. Основные ошибки и проблемы, с которыми сталкивается компания-разработчик и способы их решения.
"Этот код плохой, его нужно переписать". Слышали? Как обосноватьMaksym Bezuglyi
Как на языке бизнеса доказать необходимость переписывания кода. Как бизнес может объяснить инженерам, что этого делать не нужно, либо как сделать это правильно с перспективы бизнеса.
Документация тестировщика - Александр ТрибушныйDataArt
Как сделать документацию тестировщика лучше?
- зачем нужна матрица трассируемости?
- проблемы разработки тест-кейса;
- частые ошибки при написании баг-репорта;
- рекомендации при написании тест-кейсов и баг-репортов.
Artem Bykovets: Чому люди не стають раптово кросс-функціональними, хоча в нас...Lviv Startup Club
Artem Bykovets: Чому люди не стають раптово кросс-функціональними, хоча в нас Agile? (UA)
Kyiv PMDay 2024 Summer
Website – www.pmday.org
Youtube – https://www.youtube.com/startuplviv
FB – https://www.facebook.com/pmdayconference
Natalia Renska & Roman Astafiev: Нарциси і психопати в організаціях. Як це вп...Lviv Startup Club
Natalia Renska & Roman Astafiev: Нарциси і психопати в організаціях. Як це впливає на розробку продуктів та реалізацію інноваційних рішень (UA)
Kyiv PMDay 2024 Summer
Website – www.pmday.org
Youtube – https://www.youtube.com/startuplviv
FB – https://www.facebook.com/pmdayconference
Igor Protsenko: Difference between outsourcing and product companies for prod...Lviv Startup Club
Igor Protsenko: Difference between outsourcing and product companies for product managers and related challenges (UA)
Kyiv PMDay 2024 Summer
Website – www.pmday.org
Youtube – https://www.youtube.com/startuplviv
FB – https://www.facebook.com/pmdayconference
Kseniya Leshchenko: Shared development support service model as the way to ma...Lviv Startup Club
Kseniya Leshchenko: Shared development support service model as the way to make small projects with small budgets profitable for the company (UA)
Kyiv PMDay 2024 Summer
Website – www.pmday.org
Youtube – https://www.youtube.com/startuplviv
FB – https://www.facebook.com/pmdayconference
Anna Kompanets: Проблеми впровадження проєктів, про які б ви ніколи не подума...Lviv Startup Club
Anna Kompanets: Проблеми впровадження проєктів, про які б ви ніколи не подумали (UA)
Kyiv PMDay 2024 Summer
Website – www.pmday.org
Youtube – https://www.youtube.com/startuplviv
FB – https://www.facebook.com/pmdayconference
Anton Hlazkov: Впровадження змін – це процес чи проєкт? Чому важливо розуміти...Lviv Startup Club
Anton Hlazkov: Впровадження змін – це процес чи проєкт? Чому важливо розуміти різницю і як це впливає на результат (UA)
Kyiv PMDay 2024 Summer
Website – www.pmday.org
Youtube – https://www.youtube.com/startuplviv
FB – https://www.facebook.com/pmdayconference
Yana Bort: Ритм організації. Чи можливо синхронізувати великий ентерпрайз за ...Lviv Startup Club
Yana Bort: Ритм організації. Чи можливо синхронізувати великий ентерпрайз за допомогою Agile практик? (UA)
Kyiv PMDay 2024 Summer
Website – www.pmday.org
Youtube – https://www.youtube.com/startuplviv
FB – https://www.facebook.com/pmdayconference
2. Обо мне
• 30 years in R&D
• 17 years in Israel HighTech
• ECI, Telrad, RAD, Audiocodes companies
• HW, SW, Mechanical design engineer
• Project & Product Manager
• Business developer for EMEA & CIS countries
• 22 publications, US patent
• Counseling & SW development teaching
Email: dovnmr@gmail.com
Skype: dovnmr
3. Понятия
• Проект - временное предприятие, направленное на создание уникального
продукта, услуги или результата (PMBOK).
• Проблема - сложный теоретический или практический вопрос, требующий
изучения, разрешения
• В соответствии с ITIL проблема – неизвестная причина одного или нескольких
инцидентов.
• В каждый конкретный момент времени всегда есть главная проблема.
• Т.е. - проблема это хроническая болезнь.
• Принцип работы, как у врача - Диагностирование -> Лечение -> Профилактика
• Технические проблемы и не технические проблемы.
• Три сферы не технических проблем:
• С заказчиком
• С командой
• С начальством
• С внешними сторонами.
4. Собрать все симптомы
• Баги в фреймворке
• Нет тех поддержки
• Заказчик меняет условия
• Нет достаточно QA
• Продавец соглашается с заказчиком во всем
• Начальство не ценит - команда демотивирована
• Все устали от переработок и ушел Тим лид
• Spaghetti code
• Креши приложения
• Отставание от графика, перетрачен бюджет
5. Построить граф
зависимостей
No tech supp.
Заказчик
меняет
условия
Crash in
App.
Отставание от
графика
Bugs in
framework
Продавец
“тряпка”
Мало QA
Все устали
Ушел
ТимЛид
Spaghetti
code
Начальство
6. В ребрах писать «если бы не
было … то не было бы
связи»No tech supp.
Заказчик
меняет
условия
Crash in
App.
Отставание от
графика
Bugs in
framework
Продавец
“тряпка”
Мало QA
Все устали
Ушел
ТимЛид
Spaghetti
code
Начальство
Если бы продавец
отстаивал наши
интересы, то заказчик
не менял бы условия
7. 3. В ребрах писать «если бы
не было … то не было бы
связи»No tech supp.
Заказчик
меняет
условия
Crash in
App.
Отставание от
графика
Bugs in
framework
Продавец
“тряпка”
Мало QA
Все устали
Ушел
ТимЛид
Spaghetti
code
Начальство
Если бы заказчик не
менял условия не
было бы отставания
8. 3. В ребрах писать «если бы
не было … то не было бы
связи»No tech supp.
Заказчик
меняет
условия
Crash in
App.
Отставание от
графика
Bugs in
framework
Продавец
“тряпка”
Мало QA
Все устали
Ушел
ТимЛид
Spaghetti
code
Начальство
Если бы не было
отставания, продавец
мог бы
“сопротивляться”
11. Схема связей проблем
No tech supp.
Заказчик
меняет
условия
Crash in
App.
Отставание от
графика
Bugs in
framework
Продавец
“тряпка”
Мало QA
Все устали
Ушел
ТимЛид
Spaghetti
code
Начальство
13. Схема связей проблем
No tech supp.
Заказчик
меняет
условия
Crash in
App.
Отставание от
графика
Bugs in
framework
Продавец
“тряпка”
Мало QA
Все устали
Ушел
ТимЛид
Spaghetti
code
Начальство
15. Схема связей проблем
No tech supp.
Заказчик
меняет
условия
Crash in
App.
Отставание от
графика
Bugs in
framework
Продавец
“тряпка”
Мало QA
Все устали
Ушел
ТимЛид
Spaghetti
code
Начальство
16. Самостоятельный источник
проблемы - без обратной
связи
No tech supp.
Отставание от
графика
Crash in
App.
Bugs in
framework
Все устали
Spaghetti
code
18. Разобраться с
интерфейсом и мотивацией
Меняет
условия
Ежедневные
митинги
За что я плачу?
Заказчик
Уровень проблемы
Уровень коммуникации
Уровень мотивации
19. Разобраться с
интерфейсом и мотивацией
Потакает
заказчику
Боится
разговаривать
Страх потерять клиента
Продавец
Уровень проблемы
Уровень коммуникации
Уровень мотивации
20. Разобраться с
интерфейсом и мотивацией
Давит
на команду
Ругается с
программистами
Потеря имиджа
Начальство
Уровень проблемы
Уровень коммуникации
Уровень мотивации
21. Изменение мотивации
За что я плачу?
Заказчик
Страх потерять клиента
Продавец
Потеря имиджа
Начальство
Получить максимально
хороший продукт
22. Изменение
коммуникации
За что я плачу?
Заказчик
Страх потерять клиента
Продавец
Потеря имиджа
Начальство
Получить максимально
хороший продукт
Ежедневные
митинги
Боится
разговаривать
Ругается с
программистами
Возврат к модели
Scrum
Тесная связь с
Product owner
Составить кризис
план и митинги
по нему
23. Борьба с главной
проблемой
No tech
supp. Отставание от
графика
Crash in
App.
Bugs in
framework
Все устали
Spaghetti
code
25. План дальнейших действий
по превентивному лечению
• Обеспечить реальную поддержку от производителя framework
• Наладить общение Продавец - Product Owner - Заказчик
• Направить энергию Продавца, РО и Заказчика на
производителя Framework
• Усилить команду тестировщиками и консультантами
• Построить кризис план согласованный со всеми сторонами
• Ввести регулярные командные обсуждения с руководством
• План перехода от монолитного кода к микросервисам
Деление на технологические и не технологические проблемы
Не технологические - Заазчик и Продавец
Пирамида проблемы:1. Заказчик
Проблема - меняет условия
Коммуникация - ежедневные стендапы с его участием
Мотивация - Страх перед советом директоров
2. Продавец
Проблема - Во всем поддерживает заказчика
Коммуникация - Работает по телефону, а не в поле
Мотивация - Бояться скандала и быть уволенным
Начальство
Проблема - Давит на команду
Коммуникация - Не ведет диалога, а посылает проверяющих
Мотивация - “подхлестнуть лошадь”
Люди уходят на следующем слойке
Все устали и люди уходят - общая проблема
Коммуникация - все ругают команду
Мотивация избавиться от проекта
Источник проблемы в данном случае был не в обратных связях
Исправление ситуации - перенос давления начальства и заказчика на поставщика фреймворка.