tag:blogger.com,1999:blog-2303610479384303582024-03-12T23:34:59.886-07:00Проектная кухня. Сборник рецептовАлексей Васильевhttp://www.blogger.com/profile/16557005870298289767noreply@blogger.comBlogger15125tag:blogger.com,1999:blog-230361047938430358.post-12513340233911476642018-09-30T10:44:00.001-07:002018-09-30T11:00:11.564-07:00Девальвация Agile<div dir="ltr" style="text-align: left;" trbidi="on">
<i>Agile идет в массы, его пытаются применить во всем, зачастую даже там, где это не применимо. Но будет ли результат называться Agile? </i><i>На эту тему спонтанно пообщались с Иваном Селиховкиным. Попробовали выяснить “нужен ли agile в стройке” и плавно перешли к тому “что есть agile”. Получилось, что Иван взял у меня интервью.</i><br />
<div>
<br />
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgOGqyzT6Q3fa6xG9axqfFoYvI5nni1w3N1_qRpLGBTQxbX517cY2Bzw6B9G0RcDz761RzGguniM7oJ8cigRU2Ue0Tj4foHamY98e9TvL9FcSmT6u3-05qHCPMY3i2Y5GBC6qZgw0OZ_PVB/s1600/rit2018.jpg"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgOGqyzT6Q3fa6xG9axqfFoYvI5nni1w3N1_qRpLGBTQxbX517cY2Bzw6B9G0RcDz761RzGguniM7oJ8cigRU2Ue0Tj4foHamY98e9TvL9FcSmT6u3-05qHCPMY3i2Y5GBC6qZgw0OZ_PVB/s320/rit2018.jpg" /></a><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgqM3YENZXOr54meSYW_601XOiA8mmyXSwG_o9PaHh2qIQFHxHBLgaYTty2-pnZRuI_lsV2_JueIfvK1RaMxv2tggknojTEFBJqyMWJxjAtPhz-ViyEEZ-SEQ3hO8oTpjSp_G1zSctfZrAD/s1600/ivan.jpg"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgqM3YENZXOr54meSYW_601XOiA8mmyXSwG_o9PaHh2qIQFHxHBLgaYTty2-pnZRuI_lsV2_JueIfvK1RaMxv2tggknojTEFBJqyMWJxjAtPhz-ViyEEZ-SEQ3hO8oTpjSp_G1zSctfZrAD/s320/ivan.jpg" /></a><br />
<br />
<br />
<b></b><br />
<a name='more'></a><b><br /></b>
<b>Иван: Алексей, а применим ли Agile на стройке?</b><br />
<br />
<b>Алексей</b>: Насколько я общался со своими клиентами (у нас же решение управления проектами). у них Agile уже есть, точнее почти есть. Выполняются все действия и правила кроме Ретроспективы.<br />
<br />
<b><br />Иван: А что это значит "у них agile есть"? Скрам есть? Т.е. вместо ТЗ - бэклог, в который заказчик на свое усмотрение добавляет или убирает "фичи" разного размера и приоритезирует их? Можно пример такой стройки (пусть и без ретроспективы)?</b><br />
<b>Алексей</b>: Я имею ввиду работу на площадке.<br />
<br />
Вот смотри:<br />
- ритм планирования, синхронизации, сверки плана и факта<br />
- регулярные коммуникации <br />
- утренняя синхронизация (прораб раздающий утром наряды бригадам)<br />
- короткое планирование - план на неделю, сверка.<br />
- приоритизация - при ограниченных ресурсах на объекте я сильно сомневаюсь, что есть детальное планирование последовательности работы бригады на площадке. Исключения составляют работы по ремонту железнодорожных путей где план работ расписан поминутно.<br />
<br />
Если говорить о примерах применения CCPM (Метод критической цепи), то тут добавляется еще и фокусировка на цели (использование Full Kit - полный набор материалов, инструментов и ресурсов для выполнения работ) и устранение всех препятствий уровня поставки комплектующих. <br />
<br />
<b>Иван: Алексей, а почему ты называешь здравый смысл - agile-ом? Вот в классическом проектном управлении кто или что мешает регулярным коммуникация, утренней синхронизации (в больницах она тоже есть - но там же не принято называть управление отделением словом "agile") и так далее? :) Пока все что ты перечислил - это основа любого менеджмента вообще, разве нет?</b><br />
<b><br /></b>
<b>Алексей</b>: Чтобы применить "любой менеджмент" - нужно его знать. А тимлиды и инженеры до этого не дорастают. Тот же PMBoK дает много инструментов, но не показывает как конкретно применять всё вместе. Agile это просто типовое решение для решения определенных задач. В частности, дать инженерам прививку регулярного менеджмента.<br />
<br />
Поэтому <br />
<ul style="text-align: left;">
<li>XP - дисциплина = если будешь её следовать, то получишь хорошие результаты </li>
<li>Scrum (Метод "Уухнем") - коммуникационный каркас - выстраивает типовой процесс планирования/контроля </li>
<li>Kanban-метод - метод улучшения бизнес-процесса просто за счет метрик и правил. В нём даже про результат ничего нет. Это метод превращения любой деятельности в Производство и оптимизация оного применяя производственные принципы. </li>
</ul>
Agile описывает здравый смысл. и просто дает каркас "что делать" на уровне понимания инженеров и тимлидов не вдаваясь в тонкости управления.<br />
<br />
К тому же 90% манифеста - XP, а один из основных принципов XP - действовать в соответствии с инстинктами, а не вопреки. То есть, все правила и действия должны быть обоснованы.<br />
<br />
Единственной, отличительной чертой реальной гибкости и адаптивности - является ритм Ретроспективы. До главы "План управления улучшениями" свода Знаний (PMBoK) мало кто дочитывает. Некоторые компании проводят "разбор полетов", особенно, если было ЧП. И тогда у них Agile уже есть. Некоторые внедрили СМК и тогда у них по регламенту есть какие-то процедуры улучшения и пересмотра. <br />
<br />
<b>Иван: А можешь пояснить фразу "Единственной отличительной чертой реальной гибкости и адаптивности является ритм Ретроспективы."<br /><br />Т.е. регулярные ретро = agile, не регулярные = не agile?</b><br />
<b><br /></b>
<b>Алексей</b>: Можно сказать и так.<br />
<br />
По хорошему Agile software development (ASD)- это противостояние контрактных обязательств и адаптивного, уточняющего подхода. Но перекладывая ASD в другие отрасли мы теряем важное: у нас нет высокой неопределенности или нет объединяющей цели .<br />
<br />
Приведу примеры отличий: <br />
<ul style="text-align: left;">
<li>В стройке - этап конструирования 1-2 года, в разработке ПО - 1-5 минут (сборка проекта и получение исполняемого файла) </li>
<li>В маркетинге - нет цели вообще, сплошное экспериментирование, то есть регулярная работа в процессе. </li>
<li>В продажах - даже экспериментов нет, если цикл сделки фиксирован. Если это сложные B2B продажи, то они строятся по процессу “планирование и экспериментирование” с уточнением стратегии. Но в любом случае тут нет цели спринта, вокруг которой собирать команду и “Заказчика" </li>
</ul>
Поэтому во всех других отраслях это просто "правила хорошего процесса", цикл PDCA и регулярный менеджмент, в котором от Agile остается только фаза “Act” - корректирование процесса.<br />
<br />
Вот смотри, покажу на примере. В любой компании есть ДВА потока: <br />
<br />
Поток создания ценности, которым все умеют управлять и корректировать (план-фактный анализ и тд), он обеспечивает адаптацию компании под рынок и изменяющиеся условия внешней среды, и <br />
<br />
Поток управления - а про него забывают, это бизнес-процессы, у которых тоже есть метрики которые можно корректировать и которым нужно управлять. <br />
<br />
Agile явно прописывает правила работы во вторым потоком обеспечивает рост компании и её развитие. Про второй поток вспоминают только когда "Что-то у нас исполнительская дисциплина снизилась" или "Производительность надо повысить", то есть редко и эпизодически.<br />
<br />
В этим правилам я отношу:<br />
- ритм Ретроспективы - напрямую влияет на второй поток<br />
- правила работы с Заказчиком - влияет косвенно за счет управления ожиданиями и управление вовлеченностью Заказчика.<br />
<br />
<br />
Давай, покажу на картинке:<br />
<br />
<br />
<img height="313" src="https://lh5.googleusercontent.com/EJHal-5doFA5wgizOly_l1vFQ7NWgjXM2rQkdzsPUGf8haOj5GpgcvPhAoi2c0rOhd8u9S8f4ESmhxUmMQfCqXOIXXWrUbUWvONdgXUGuOtSr-OvuyhKwoxpHSKU7lzRcluqjlfa" width="640" /><br />
<br />
Уж какая есть, это из нашей презентации решения.<br />
<br />
<br />
<b>Иван: А какие в agile есть метрики, которых нет в проектном управлении? Пример можешь привести?</b><br />
<br />
<b>Алексей</b>: В том то и дело, что они все есть в проектном управлении! Или они выводятся исходя из целей, например: график "настроения команды".<br />
<br />
<b>Иван: Я правильно тебя понимаю, что очень многое на свете - есть agile. И лишь немного agile-ом не является? Вот проектное управление в грамотных руках - agile. Управление хирургическим отделением в стационаре (там регулярные ретроспективы каждое утро) - agile. И так далее?</b><br />
<b><br /></b>
<b>Алексей</b>: Да, именно так!<br />
<br />
Компания по определению не может быть "не agile" она просто помрёт тогда. Потому, что нужно адаптироваться, рынок меняется, сезонность влияет, клиент меняется. У кого-то процессы отточены до совершенства управляемого уровня CMMI-4 и улучшаемого CMMI-5, а кто-то действует по наитию на уровне CMMI-1 адаптируясь, когда совсем прижмет (идем к врачу когда зуб уже болит).<br />
<br />
Если смотреть в корень, то в американских компаниях были (и сейчас есть) распространены кубиклы, а у нас такого количества перегородок вообще никогда не было, максимум кабинет на отдел, и кубикл на сектор (если повезет). Это разница культуры индивидуализма и культуры сообществ (землячество)<br />
<br />
И это важно, поэтому у нас нет ломки "личного пространства", и уже есть высокий уровень командной поддержки, поэтому часто, не нужны утренние планерки.<br />
<br />
<b>Иван: Я понял. Спасибо. Но тогда термин agile очень сильно девальвируется.</b><br />
<br />
<b>Алексей</b>: Да! Но его пихают везде. Это хороший бренд, который продается. Однако, знакомясь с компанией я спрашиваю "А вам зачем Agile?" и "Что беспокоит собственника? На что жалуетесь?" - и в первую очередь выстраиваю систему управления отменяя лишние или улучшая нужные правила.<br />
<br />
Agile software development - это конкретный способ достижения конкретных результатов в конкретной сфере. А чтобы он заработал, нужно создать экосистему. У этого способа есть ограничения которые находятся выше него (например много-клиентская среда). И где включаются инструменты проектного управления и Теории ограничений (ТОС).. <br />
<br />
Если сменить сферу - остается только ритм PDCA и нужно иметь ответы на вопросы "А что будет означать эта практика в этой области?"<br />
<br />
<i>На этой ноте нам пришлось прерваться.</i><br />
<br /></div>
</div>
Алексей Васильевhttp://www.blogger.com/profile/16557005870298289767noreply@blogger.com0tag:blogger.com,1999:blog-230361047938430358.post-43081203198460570422017-05-01T09:17:00.002-07:002017-05-01T12:05:46.745-07:00Притча о стендапах<div dir="ltr" style="text-align: left;" trbidi="on">
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjG7ZUoKqWjf4ABIcXnhjzn4eL1ydVL21aBkO0ceowZs9BIEG6zk9FLvK1zkpglCbz8pBAfXXlvgPSxW3KSO0_1aJfX1xEE4cjkQNTmi0y5za4spALNH_dC59QQNhylmwWPhYDT8IVLj21e/s1600/meditation-2214532.jpg" imageanchor="1" style="background-color: white; color: #252525; font-family: sans-serif; font-size: 14px; margin-left: 1em; margin-right: 1em;"><img border="0" height="360" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjG7ZUoKqWjf4ABIcXnhjzn4eL1ydVL21aBkO0ceowZs9BIEG6zk9FLvK1zkpglCbz8pBAfXXlvgPSxW3KSO0_1aJfX1xEE4cjkQNTmi0y5za4spALNH_dC59QQNhylmwWPhYDT8IVLj21e/s640/meditation-2214532.jpg" width="640" /></a></div>
<div style="line-height: inherit; margin-bottom: 0.5em; margin-top: 0.5em; max-width: 20cm;">
<br />
<br />
Один Ученик, начинающий Scrum Master, хотел внедрить у себя в компании Agile практики, но у него ничего не получалось. И вот он решил пойти к Учителю и спросить.<br />
<br />
— Учитель, а скажи, почему у меня никак не получается внедрить ежедневные короткие 5 минутки? — спросил Ученик.<br />
<br />
— Как-это так не получается? — спросил Учитель<br />
<br />
— Ну так, очень просто! Я их собираю на совещание, а они говорят: "Надоели нам эти совещания, нету в них смысла, что мы еще там еще не видели?"<br />
<br />
— Интересно... — задумчиво пробормотал учитель, и продолжил — А какие вопросы им задаешь?<br />
<br />
— Самые обычные! — ответил Ученик — Что ты сделал вчера? Что планируешь делать сегодня?<br />
<br />
— Хорошо — ответил Учитель — А ты точно уверен, что им всем интересно знать что делают их коллеги?<br />
<br />
— Конечно интересно! — воскликнул Ученик — Мы же Agile команда, а эти пятиминутки прописаны в правилах!<br />
<br />
— Ты уверен? — спросил Учитель.<br />
<br />
— На все сто процентов! — воскликнул Ученик<br />
<br />
Учитель немного подумал, понимающе взглянул на Ученика, и сказал — Хорошо, а теперь иди и подумай. Еще раз внимательно-внимательно подумай над этими вопросами — и сделал отсылающий жест рукой.<br />
<br />
Ученик вышел от Учителя. Но остался недоумении, он получил ответ на свой вопрос, и не получил ответа.</div>
</div>
Алексей Васильевhttp://www.blogger.com/profile/16557005870298289767noreply@blogger.com0tag:blogger.com,1999:blog-230361047938430358.post-91299373507938433782017-02-07T13:16:00.001-08:002017-02-07T13:19:34.662-08:00Откуда мифы про Agile<div dir="ltr" style="text-align: left;" trbidi="on">
Сейчас много говорят о гибких подходах к разработке программного обеспечения. И даже пытаются внедрить для выполнения гос. контрактов. С другой стороны, много компаний спотыкаются на этих подходах. И хотя в компаниях делают что нужно, и даже Scrum-мастер в них есть, программный Продукт почему-то перестает развиваться, и появляется много задач на исправление дефектов. Давайте разберемся почему так происходит.<br />
<br />
<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg9eG7UT6F4C_lQK-Wk7LsP87NoFOuK4oBGhJ7m-KqSQkefAD4DDBMQ2oRUx-fM3Xkm9OYqkBf3YzohU9q-N-mJwdJPCjz7fNXXvBmjuG-9Cl67_ocSvbgM5SJ_K2j-dAce5FClftJOkjxw/s1600/dragon-32887_640.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="347" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg9eG7UT6F4C_lQK-Wk7LsP87NoFOuK4oBGhJ7m-KqSQkefAD4DDBMQ2oRUx-fM3Xkm9OYqkBf3YzohU9q-N-mJwdJPCjz7fNXXvBmjuG-9Cl67_ocSvbgM5SJ_K2j-dAce5FClftJOkjxw/s640/dragon-32887_640.png" width="640" /></a></div>
<br />
<br />
<h2 style="line-height: 1.1; margin-bottom: 10px; margin-top: 20px;">
<a name='more'></a></h2>
<h2 style="line-height: 1.1; margin-bottom: 10px; margin-top: 20px;">
Как дошли до жизни такой</h2>
<div style="margin-bottom: 10px;">
Гибкие подходы к разработке программного обеспечения, начали применяться в России с 2002 года, после выхода книжек Кента Бека "Экстремальное программирование" (XP). Но, настоящую популярность принес Scrum, во главе со Scrum Alliance и сертификацией Scrum-мастеров. Всем понравилась простота применения, игры в планирование, геймификация ретроспектив, и очевидные ежедневные планерки, которые ранее применялись на заводах и в конструкторских бюро. И все уверовали в то, что можно меньше писать документации и больше общаться, а код сам по себе создастся качественным.</div>
<div style="margin-bottom: 10px;">
В результате, получилась интересная штука. Благодаря хорошей пропаганде (сертификация Scrum-мастера стоит не маленьких денег) под Agile-процессом разработки ПО начали понимать Scrum и наоборот. Но, зачастую при внедрении Scrum, и практик улучшающих общение, забыли об инженерных техниках обеспечивающих качественную разработку ПО.</div>
<div style="margin-bottom: 10px;">
В итоге, Agile превратился в карго-культ в который верят. А программный продукт, как не разрабатывался хорошим, так и не разрабатывается.</div>
<h2 style="line-height: 1.1; margin-bottom: 10px; margin-top: 20px;">
Взгляд назад</h2>
<div style="margin-bottom: 10px;">
Давайте посмотрим внимательней на историю движения Agility применительно к разработке ПО.</div>
<div style="margin-bottom: 10px;">
Основным конфликтом который решался был следующий:</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjacXKDY2ykslKCkXCleOSLzFfcmHGnz2uuzorULUFQy9KkTx_PkoNwE8MT7oM_EmH2q4oSC_ScYu5Is5TadeT139j4segFAjQPgVPtpZMoWPXSRJtJ6aj56nBFZqvV_dImEu83f4vh2HDM/s1600/conflict.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjacXKDY2ykslKCkXCleOSLzFfcmHGnz2uuzorULUFQy9KkTx_PkoNwE8MT7oM_EmH2q4oSC_ScYu5Is5TadeT139j4segFAjQPgVPtpZMoWPXSRJtJ6aj56nBFZqvV_dImEu83f4vh2HDM/s1600/conflict.png" /></a></div>
<div style="margin-bottom: 10px;">
<br /></div>
<div style="margin-bottom: 10px;">
Для того чтобы <em>Заказчик был доволен</em>, нужно создать <em>качественное и полезное </em>программное обеспечение. Для создания качественного Продукта, нужно <span style="font-weight: 700;">не менять требования</span> в процессе разработки ПО. И одновременно с этим, чтобы создать полезный Продукт, нужно <span style="font-weight: 700;">корректировать требования</span> к Продукту, адаптировать под потребности. Нельзя одновременно менять требования и <span style="font-weight: 700;">не</span> менять требования.</div>
<div style="margin-bottom: 10px;">
Но как же тогда быть? Когда нельзя, но очень хочется, то можно. И авторы XP задумались: как бы сделать так, чтобы требования можно было менять (корректировать), а продукт был качественным?</div>
<div style="margin-bottom: 10px;">
Основной нежелательный эффект изменений требований к ПО состоит в том, что программный комплекс очень сложный, и изменение в одном месте может повлечь за собой непредсказуемое поведение в других местах. Для снижения влияния этого эффекта следует использовать модульные тесты, непрерывный рефакторинг и непрерывную интеграцию.</div>
<div style="margin-bottom: 10px;">
Таким образом, все инженерные техники XP увязывались в единую систему:</div>
<ol style="margin-bottom: 10px; margin-top: 0px;">
<li>чтобы реализовать новые требования нужен рефакторинг существующего кода;</li>
<li>чтобы рефакторинг ничего не сломал - нужны модульные тесты;</li>
<li>чтобы модульные тесты всегда срабатывали - одни должны запускаться каждый день на интеграционном сервере;</li>
<li>Чтобы тесты не забывали писать - их нужно писать ДО кода (техника Test Driven Develpment (TDD));</li>
<li>Чтобы тесты было не лень писать - нужно это делать вдвоем.</li>
</ol>
<div style="margin-bottom: 10px;">
С другой стороны, необходимо не забывать и о Заказчике, и о том чтобы вовремя знать что он задумал и держать его в курсе. А также держать в курсе и всю команду:</div>
<ol style="margin-bottom: 10px; margin-top: 0px;">
<li>чтобы вовремя узнать об изменении требований - нужно часто поставлять результат Заказчику;</li>
<li>Чтобы вся команда была в курсе где, кто и что рефакторит - нужно общаться каждый день;</li>
<li>Чтобы улучшать подходы к разработке - нужно обсуждать результаты на ретроспективе в конце итерации.</li>
</ol>
<div style="margin-bottom: 10px;">
Как следствие, если мы из всей системы практик вынем хоть один кирпич, то система рухнет и похоронит Продукт. Что впрочем и получается.</div>
<div>
<br /></div>
<div>
<h2 style="line-height: 1.1; margin-bottom: 10px; margin-top: 20px;">
Что имеем</h2>
<div style="margin-bottom: 10px;">
Как результат неполного применения всех техник лежащих в основе появились мифы описанные в статье <a href="http://reqcenter.pro/agile-myths" hreflang="ru" style="background: transparent; color: #337ab7; text-decoration: none;" title="Hayim Makabee. Конец Agile: смерть от примитивизма. //Практика проектирования систем.-2015">Hayim Makabee. Конец Agile: смерть от примитивизма. //Практика проектирования систем.-2015.</a>.</div>
<ol style="margin-bottom: 10px; margin-top: 0px;">
<li>Миф 1. Хорошие проектные решения рождаются при реализации User Stories.</li>
<li>Миф 2. Технический долг всегда можно оплатить в будущем</li>
<li>Миф 3. Постоянный рефакторинг — это эффективный способ создания кода</li>
<li>Миф 4. Гибкость может быть обеспечена за счет следования Agile процессу.</li>
</ol>
<div style="margin-bottom: 10px;">
Но я думаю, что и эти мифы возникли не на пустом месте. Корневая причина этих мифов в том что, вместо применения полноценного процесса XP, который и был базой для Agile-подхода , все пользуются Scrum- коммуникационным фреймворком, который просто не покрывает всех потребностей разработки программного обеспечения.</div>
<h2 style="line-height: 1.1; margin-bottom: 10px; margin-top: 20px;">
Итог</h2>
<div style="margin-bottom: 10px;">
Никакую практику нельзя применять бездумно, просто потому, что это модно или так сказал ОН. Всегда! Всегда нужно думать наперед.</div>
<div style="margin-bottom: 10px;">
Модульные тесты (TDD) позволяют сразу проверять, и создавать нужные программные интерфейсы. Но они не защищают от неправильной архитектуры. В момент написания теста мы думаем тактически, а не стратегически. Это приводит к реализации непродуманных решений, и не готовность к изменениям в будущем.</div>
<div style="margin-bottom: 10px;">
Хорошая техника "Парное программирование", обеспечивает думание стратегически на лету. При парном программировании один ВСЕГДА будет "навигатором" - стратегом (без клавиатуры), а второй "пилотом" за клавиатурой. Это позволяет охватывать сразу весь код в общем, и принимать решения по месту.</div>
<div style="margin-bottom: 10px;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEheOP16PLUXqvOENayGegWlX8qd2v-7EJVFd57dBTbrHc7JKoFInSHrxHZylktEbc8Js11jeJMOFqLmJ8FjqwuFRWm7WwIlRUHmgfkI2wm5Cwasovl-2xbjclbIs5T2GkfUNod8GXLVkoAR/s1600/xp.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEheOP16PLUXqvOENayGegWlX8qd2v-7EJVFd57dBTbrHc7JKoFInSHrxHZylktEbc8Js11jeJMOFqLmJ8FjqwuFRWm7WwIlRUHmgfkI2wm5Cwasovl-2xbjclbIs5T2GkfUNod8GXLVkoAR/s1600/xp.png" /></a></div>
<div style="margin-bottom: 10px;">
<br /></div>
<div style="margin-bottom: 10px;">
В Методологии XP нигде не написано "Не пишите документацию". Коммуникации важнее документации, но если документация является способом коммуникации, то система Wiki обеспечивает создание этой документации ровно в том объеме в котором надо. Что, в свою очередь, улучшает синхронизацию пары (пилот-навигатор) и создание качественного кода за счет проработки и обсуждения архитектуры.</div>
<div style="margin-bottom: 10px;">
Также, в практиках Экстремального Программирования нигде не написано "делайте технический долг и сделаете заказчика счастливым" , там написано "делайте непрерывный рефакторинг, тесты защитят вас. да прибудет с вами Сила". Это значит что при завершении КАЖДОЙ задачи не должно оставаться технического долга. Совсем.</div>
<div style="margin-bottom: 10px;">
В Методологии XP, также, не написано "Не проектируйте всю систему наперед". Там написано "Будьте готовы к изменениям", это значит, что необходимо делать архитектуру в меру гибкой, и одновременно с этим в меру достаточной для реализации известного объема работ и демонстрации частого результата Заказчику.</div>
<div style="margin-bottom: 10px;">
<br /></div>
<h2 style="line-height: 1.1; margin-bottom: 10px; margin-top: 20px;">
Заключение</h2>
<ol style="margin-bottom: 10px; margin-top: 0px;">
<li>Поклонение карго-культу и механистическое выполнение действий не даст нужного эффекта. А может сделать еще хуже.</li>
<li>Если вы не применяете хоть одну из техник XP - вы не построите продукт с Agile. Он разрушится по пути.</li>
<li>У каждого участника команды должно быть понимание зачем нужна та или иная техника. ибо смотри п.1</li>
<li>Никогда не останавливайтесь на достигнутом, всегда можно что-то улучшить. Не поддавайтесь инерции.</li>
</ol>
<h2 style="line-height: 1.1; margin-bottom: 10px; margin-top: 20px;">
Литература</h2>
<ol style="margin-bottom: 10px; margin-top: 0px;">
<li>Экстремальное программирование. Кент Бек</li>
<li>Мифический человеко - месяц или Как создаются программные системы. Фредерик Брукс</li>
<li>Профессиональная разработка программного обеспечения. Макконнелл С.</li>
<li>Цель. Элия М.Голдратт, Джефф Кокс</li>
</ol>
<h2 style="line-height: 1.1; margin-bottom: 10px; margin-top: 20px;">
Послесловие</h2>
<div style="margin-bottom: 10px;">
Q: А бывают ли проекты по Scrum успешными?</div>
<div style="margin-bottom: 10px;">
A: Только если они делаются с применением практик XP. Или в случае если весь проект выполняется менее чем за 1 месяц под ключ.</div>
<div style="margin-bottom: 10px;">
<br /></div>
<div style="margin-bottom: 10px;">
<i>Ранее опубликовано в моем корпоративном блоге <a href="http://bipulse.ru/blog/index.php?post/2016/03/agile-myths-roots">http://bipulse.ru/blog/index.php?post/2016/03/agile-myths-roots</a></i></div>
</div>
</div>
Алексей Васильевhttp://www.blogger.com/profile/16557005870298289767noreply@blogger.com0tag:blogger.com,1999:blog-230361047938430358.post-21785230339705144152015-10-06T15:34:00.002-07:002015-10-08T01:41:52.997-07:00YouTrack и управление портфелем проектов<div dir="ltr" style="text-align: left;" trbidi="on">
<br />
Мне кажется, что сообществу YouTrack это будет полезно, но я не нашел где оно живет. <br />
<br />
Для разработчика, YouTrack весьма полезная штука, рядовому исполнителю не нужно думать о планах проекта и нагружать свой мозг непонятной менеджерской фигней. Для того чтобы просто делать свою работу разработчику достаточно сидеть в списке задач с фильтром "только мне" и делать влетающие задачи, потом выставлять на них исполнителем QA инженера, менять статус и отправлять дальше.
<br />
<br />
Но что делать менеджеру который хочет управлять проектом или даже не одним? И знать, успеваем ли мы в сроки? Не пора ли идти к заказчику договариваться? Кто и какие задачи сейчас делает и какой у них личный план? Когда освободится Вася чтобы загрузить его новым проектом?
<br />
<br />
<a name='more'></a>Я сколько ни пытался, так и не смог получить ответы на эти простые вопросы от YouTrack простым способом. То ли я неправильно его готовлю, то ли я хочу от него большего чем просто трекинг дефектов.
<br />
<br />
Когда я что-то не могу получить, а очень хочется, то я это делаю сам. В этом случае
пришлось прикрутить двустороннюю интеграцию c YouTrack к инструменту стратегического планирования - <a href="http://bipulse.ru/" target="_blank">BiPulse</a>.
<br />
<br />
Подсистема интеграции вытаскивает из YouTrack всё что относится к времени и планам, а все изменения на стороне BiPulse-a вносит обратно, в том числе и информацию об этапах работ (версиях). В результате чего, получилась весьма взрывная смесь:
<br />
<br />
YouTrack - обеспечивает привычный для разработчика интерфейс работы с дефектами
<br />
<a href="http://bipulse.ru/" target="_blank">BiPulse</a> - отвечает на менеджерские вопросы о проектах и позволяет управлять проектами по методу критической цепи, что делает SCRUM надежным к поставке в срок, этакий Enterprise SCRUM
<br />
<br />
Если кто хочет попробовать BiPulse в работе, пишите мне в личку avasilyev@bipulse.ru, или звоните +7-965-776-44-08 расскажу, сделаю бесплатный аккаунт на год.
<br />
<br /></div>
Алексей Васильевhttp://www.blogger.com/profile/16557005870298289767noreply@blogger.com0tag:blogger.com,1999:blog-230361047938430358.post-50002794953974605802015-08-22T10:35:00.002-07:002015-08-22T15:15:07.873-07:00Построение идеальной компании.<div dir="ltr" style="text-align: left;" trbidi="on">
Работа мечты, это когда ты делаешь то, что тебе нравится, а тебе за это еще и деньги платят. А если и место работы нравится, то работать вдвойне приятнее.
<br />Наверное, работа в сфере разработки программного обеспечения наиболее показательный пример, когда с одной стороны это конвейерное производство изделия, а с другой стороны это сообщество энтузиастов которым нравится то, что они делают и место где они это делают. <br />
<br />
<a name='more'></a>Однако, если каждый сотрудник – энтузиаст своего дела, то качество результата сильно зависит от увлеченности сотрудника в достижение целей компании. Но как вы знаете, цели у каждого сотрудника могут быть свои собственные и каждая прогрессивная компания всегда думает над тем, как сделать так, чтобы цели компании стали целями сотрудника. Для этого основатель компании и кадровики применяет различные средства, от простых инструментов мотивации ("у нас есть печеньки") до преобразования компании в форму удобную для сотрудников. <br />
<br />
<b>Против кого дружим? </b><br />
<br />
Один из простых инструментов повышения результативности энтузиастов это соревнования против кого-то. Люди наиболее результативнее работают когда они соревнуются между собой, но еще более эффективнее это может быть если они объединяются в группы против кого-то или чувствуют общность. Если тот, против кого объединились, внутри компании, это проблема. Такая компания находится на грани развала. Но если этот "враг" снаружи, то это может дать хороший импульс к развитию. <br />
<br />
Как и в достижении любой цели которая должна соответствовать критериям SMART CLEAR PURE, дружить нужно против "врага" с кем можно объективно сравнить, например по количественным показателям: больше продаж, больше оборот, больше проектов, первое место на рынке. Но если "врагов" – конкурентов на рынке много, то как же выбрать цель "против кого дружить"? Это сложно, тогда компания применяет другой психологический ход "Мы лучшие", "Часть команды - часть корабля". <br />
<br />
<b>Мы лучшие </b><br />
<br />
"Мы лучшие" — девиз простой, но сложно реализуемый. Каждый должен чувствовать свою сопричастность к общему результату. А чтобы каждый чувствовал свою сопричастность к результату компании нужно, чтобы каждый МОГ и главное ХОТЕЛ что-то изменить в компании. Именно на этом шаге останавливаются большинство начинаний. Если сотрудник видит что его предложения остаются без внимания, он перестает хотеть что-то улучшать и достигать, а потом его продуктивность падает и он становится "копателем" (могу копать - могу не копать). <br />
<br />
Девиз "Мы лучшие" Нельзя просто декларировать, ему нужно следовать и показывать на личном примере каждый день. И если основатель компании это понимает и готов к быть проводником изменений и быть евангелистом, то он действительно сможет построить компанию №1. <br />
<br />
Но может ли кто-то другой преобразовать компанию? К сожалению нет, даже с согласия основателя фирмы. Потому что люди четко видят позицию руководства, и если руководству "ничего не надо" и то и у сотрудниках на местах установка "не дергайся" и "не высовывайся". <br />
<br />
<br />
<b>На что менять? </b><br />
<br />
Когда понимание необходимости изменений приходит основателям, они, начитавшись бизнес литературы, принимают решение "Нам нужен менеджер" или "Нам надо сделать подразделения" но на вопрос "Зачем?" может последовать ответ "ну так рекомендуют в умных книжках". И получаются истории типа такой: внедрили менеджмент, увидели что не работает, и разогнали. <br />
<br />
Но как изменять правильно? Когда есть правило "работает не трогай", но в тоже время "все хорошо, но чего-то не хватает и надо бы поменять". Для решения этого конфликта утверждений имеет смысл, как минимум, воспользоваться простым алгоритмом: записать что есть,<br />
<ol style="text-align: left;">
<li> четко определить чего хочется,</li>
<li> выяснить что мешает достичь желаемого эффекта минимальными усилиями </li>
<li> выработать решение достижения цели </li>
<li> проверить что решение действительно будет работать.</li>
</ol>
После чего, по шагам менять структуру или внедрять практики. То, что работает для больших организаций не будет работать в маленьких, и то, что эффективно работает в маленьких уже не работает хорошо в больших. У каждой компании есть свой уникальный рецепт приготовления бизнес процессов который будет работать только в с этим основателем, только с этими сотрудниками, только в этом регионе. <br />
<br />
<br />
Об особенностях построения бизнес-процессов некоторых компаний в Европе и шла речь на прошедшей 13 августа встрече с<a href="https://plus.google.com/u/0/+SergeyKotlov/posts" target="_blank"> Сергеем Котловым </a> посвященной компаниям с сердцем и душой .<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<iframe allowfullscreen="" class="YOUTUBE-iframe-video" data-thumbnail-src="https://i.ytimg.com/vi/GeoHmiwCHtY/0.jpg" frameborder="0" height="266" src="https://www.youtube.com/embed/GeoHmiwCHtY?feature=player_embedded" width="320"></iframe></div>
<br />
<br /></div>
Алексей Васильевhttp://www.blogger.com/profile/16557005870298289767noreply@blogger.com3tag:blogger.com,1999:blog-230361047938430358.post-10601028212160080702015-08-13T15:51:00.001-07:002015-08-22T10:18:57.585-07:00Что такое "качество"? - Это сервис. Сервис для клиента...<div dir="ltr" style="text-align: left;" trbidi="on">
10 августа прошло очередное событие от <a href="http://fi.co/" target="_blank">Founder Institute</a> прошло на площадке 404 Hub.
В этот раз были компании представляющие финансовый сектор, но важно не из какого сектора компания, а каково их понимание <b>качества</b> у каждой из них.<br />
<br />
В данном случае все компании являются сервисными, но именно правильное понимание качества отличает эти компании из множества других, что позволяет им отвоевывать у рынка свою долю и привлекать новых клиентов.<br />
<br />
<a name='more'></a><br />
<ul style="text-align: left;">
<li>Алексей Колесников из Рокетбанка, рассказывал о сервисе с человеческим лицом. </li>
<li>Яков Новиков из Modulbank банка рассказывал про тернистый путь построения банка для "нелюбимого ребёнка" банковского сектора - малого предпринимателя.</li>
<li>Владимир Акимов из LifePay поделился историей успеха компании, о том, как управлять впечатлениями бизнес пользователей. </li>
<li>Сергей Тихомиров из LiveTex рассказывает о важности решения истинных проблем клиента , а не только предоставления ему инженерного решения одной задачи. </li>
</ul>
Видео прошедшего мероприятия есть в конце статьи. Но я хотел бы немного поговорить о качестве.<br />
<br />
<br />
<br />
"Качество" всем нужно, но не все понимают как его достигнуть. И часто "у нас есть система менеджмента качества ISO9000" сводится только к исполнению каких-то регламентов, о назначении которых знает только тот, кто их пытается внедрить. Потому что никому больше, в компании, это вообще не нужно.<br />
<br />
Можно рассматривать "качество" как тождественность выражению "чтобы заказчик был доволен". Но как обеспечить довольного заказчика? Самый простой путь, это все свалить на службу поддержки или продажников, мол "это их зона ответственности путь и отдуваются". Но будет ли достигнут в этом случае нужный уровень качества?<br />
<br />
Представим ситуацию: Вы в автосалоне, менеджер по продажам хорошо пообщался с вами, красиво все рассказал о машине и убедил купить. Но после покупки вы выясняете что в ней что-то не работает и у вас появляется негатив к автосалону, производителю и конкретному менеджеру в частности. Но менеджер по продажам как бы ни хотел исправить положение, это уже не его зона ответственности, это производство. А производству проблемы клиента как-то "до фонаря" им главное план делать, а то премию не получат. Или бывает что они просто хотят делать свою работу и получить за нее деньги. А цели компании их не интересуют.<br />
<br />
А в итоге что получается? Не будет работать ни ISO9000 , ни регламенты. Потому что о клиенте заботится только первая линия вместо каждого сотрудника компании.<br />
<br />
Что делать? Как минимум перестроить мышление каждого сотрудника, что забота о клиенте это его часть обязанностей. Ведь только в случае когда каждый сотрудник думает о качестве для клиента только так можно достигнуть <strike>просветления</strike> нужного уровня качества. Однако, для того чтобы правильно заботиться о клиенте, нужно устранять все проблемы заранее, а значит нужно постоянно думать об улучшении компании. О чем и говорят очень старые, но ныне модные методологии <br />
<ul style="text-align: left;">
<li>Бережливое производство.</li>
<li>Философия Кайдзен</li>
<li>Теория Ограничений систем</li>
</ul>
<br />
"Это все конечно хорошо и красиво" -- можете сказать вы, но что делать если сотрудники хотят ничего менять, они просто делать свою работу. И ваши хотелки об улучшениях им по барабану?<br />
Тогда подумайте не будет ли такой сотрудник являться деструктивным элементом отрицательно влияющим на систему в целом? <br />
Иногда проще заменить, чем переучить.<br />
<br />
<br />
<br />
Видео с мероприятия:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<iframe allowfullscreen="" class="YOUTUBE-iframe-video" data-thumbnail-src="https://i.ytimg.com/vi/rrKwwt7rmuY/0.jpg" frameborder="0" height="266" src="https://www.youtube.com/embed/rrKwwt7rmuY?feature=player_embedded" width="320"></iframe></div>
<br />
<div class="separator" style="clear: both; text-align: center;">
<iframe allowfullscreen="" class="YOUTUBE-iframe-video" data-thumbnail-src="https://i.ytimg.com/vi/3mUR-TkB7lo/0.jpg" frameborder="0" height="266" src="https://www.youtube.com/embed/3mUR-TkB7lo?feature=player_embedded" width="320"></iframe></div>
<br />
<br />
<br /></div>
Алексей Васильевhttp://www.blogger.com/profile/16557005870298289767noreply@blogger.com0tag:blogger.com,1999:blog-230361047938430358.post-8706979069986156362015-06-26T08:19:00.004-07:002015-06-29T14:58:40.328-07:00Новые знания? Бесплатно?? В Живую??? - не верю<div dir="ltr" style="text-align: left;" trbidi="on">
Кто еще не знает, то есть инициатива <a href="http://piter-united.ru/" target="_blank">Piter-United</a> - объединение IT сообществ Санкт-Петербурга. И в рамках этих сообществ есть несколько которые могут быть очень полезными для менеджера проектов для развития своих компетенций:<br />
<br />
<ul style="text-align: left;">
<li>Клуб Менеджеров проектов связанных с разработкой программного обеспечения <a href="http://spbspm.club/" target="_blank">SPB SPM Club</a>. </li>
<li><a href="http://agilepiter.ru/" target="_blank">AgilePiter</a> - практики гибкой разработки программного обеспечения. </li>
<li>Сообщество аналитиков - CoA</li>
</ul>
<br />
И у этих сообществ, которые существуют, как бы "виртуально", случаются встречи, иногда редко, иногда регулярно. На встречах можно пообщаться с коллегами по цеху, оспорить прописные истины или получить ответ на свой вопрос. Кроме этого, Вы можете сами прийти и поделиться знаниями которые у вас есть. Предложить свою идею, показать интересный прием. <br />
<br />
Если вы сомневаетесь, "а стоит, ли ?" , а что там? "А вдруг меня там попинают". Не бойтесь.<br />
<br />
<a name='more'></a><br />
<br />
Я могу немного приоткрыть завесу и показать что у нас происходит на встречах. Есть видео с наших встреч которые я публикую на <a href="http://www.youtube.com/user/comm644/videos" target="_blank">YouTube</a>. <br />
<br />
Например из последних:<br />
<br />
<br />
Июньская встреча - Agility это...<br />
<br />
<iframe allowfullscreen="" frameborder="0" height="315" src="https://www.youtube.com/embed/Tij-vmRUF5s?list=PLNbnkNz7aLjb0zHBC_zEsJ2c0OlTr3drJ" width="560"></iframe>
<br />
<br />
Круглый стол - Мотивация. Что работает, что нет.
<br />
<iframe allowfullscreen="" frameborder="0" height="315" src="https://www.youtube.com/embed/qXGyoYqu4TA?list=PLNbnkNz7aLjb0zHBC_zEsJ2c0OlTr3drJ" width="560"></iframe>
<br />
<br />
Майская встреча - Мастер-класс по ТРИЗ (теория решения изобретательских задач)<br />
<iframe allowfullscreen="" frameborder="0" height="315" src="https://www.youtube.com/embed/5jpELN-vxqY?list=PLNbnkNz7aLjZwNRF8a_l4peLwtjn4c4CV" width="560"></iframe>
<br />
<br />
Видео дает узнать что происходит у нас на встречах, но будет лучше если Вы сами придете на встречу сообщества и расскажите о своем уникальном опыте применения техник и практик. О ваших набитых шишках и полученном опыте, возможно кто-то другой в совершенно другой компании бьется над теми же самыми вопросами. Не на все вопросы можно получить ответы с SCRUM Guide и PMBOK, Всегда интересен "живой" опыт или совет.<br />
<br />
<br /></div>
Алексей Васильевhttp://www.blogger.com/profile/16557005870298289767noreply@blogger.com2tag:blogger.com,1999:blog-230361047938430358.post-26460273884139454862015-06-12T03:47:00.000-07:002015-07-01T10:47:36.824-07:00Применение теории ограничений систем для постановки процессов. (ITGM5)<div dir="ltr" style="text-align: left;" trbidi="on">
<br />
<div dir="ltr" style="text-align: left;" trbidi="on">
В деятельности менеджера всегда есть какая-то доля работы связанная с постановкой <b>бизнес-процессов</b>. Как правило это необходимо когда появляются новые потребности компании, бОльший оборот , лучшая стабильность по денежному потоку или просто внедрить каике-то улучшения. Иногда бывает, что мы сталкиваемся только с симптомами или нежелательными явлениями, когда что-то идет не так: "продалбываем" сроки, заказчик недоволен, слишком большие расходы на содержание инфраструктуры или иные издержки. Между этими двумя позициями есть общая деталь: если есть потребность к изменению значит что-то эти улучшения сдерживает, и это можно расценивать как нежелательное явление. Когда мы начинаем разбираться в ситуации, то можем собрать множество разрозненных фактов из которых понятно только то, что изменения требуются. но с чего начать? Как минимальными усилиями провести изменения?
<br />
И тоже самое можно сказать о конфликтах в команде. Когда видишь конфликт интересов но решить его в лоб, административным рычагом, будет не самым правильным выходом. Нужно искать корневую причину конфликта и решать ее.
<br />
<cut text="Алгоритм решения">
</cut><br />
<h2>
<a name='more'></a></h2>
<h2 style="text-align: left;">
Ищем причины </h2>
Часто, анализируя деятельность компании мы видим множество разрозненных но очевидных фактов типа:
<br />
<ul>
<li> заказчик недоволен
</li>
<li> много ошибок в коде
</li>
<li> много доработок при сдаче
</li>
<li> не успеваем со сроками
</li>
<li> долго разрабатываем
</li>
</ul>
<br />
Могут ли эти факты быть ключевой проблемой которую. надо решать? - Могут, а могут и не быть. Пока мы не попытаемся связать их в дерево причинно следственных связей.
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgW1MxROADHG1zHmn_UmvIKMHR5w3u8yvtwhyzt9OS90bgLWr1csDPxdoUbq7gghLy0IVUvVpqLn8khyAOStb_D7FYRlC1Ol1RMvQdLJdmN7V9Cm_WgJybhIQ0sxH3AvEV9J-UqXIRxqeSy/s1600/toc-course-tree-0.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="302" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgW1MxROADHG1zHmn_UmvIKMHR5w3u8yvtwhyzt9OS90bgLWr1csDPxdoUbq7gghLy0IVUvVpqLn8khyAOStb_D7FYRlC1Ol1RMvQdLJdmN7V9Cm_WgJybhIQ0sxH3AvEV9J-UqXIRxqeSy/s400/toc-course-tree-0.png" width="400" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
</div>
Диаграмма называется <b>"дерево текущей реальности"</b> и её следует читать как: "ЕСЛИ мы не успеваем со сроками ТО заказчик недоволен".
<br />
Можно на этом и остановиться, и сказать "Ура! я нашел проблему и пойти долбать разработчика." И даже если вы найдете идеальных разработчиков проблемы не решатся.
<br />
Потому что скорее всего это не является истинной причиной проблемы. И нужно копать дальше.
<br />
Именно об этом говорит пятый шаг 5 ТОС "не поддавайтесь инерции". Конечно дерево не полное, И факт "много ошибок в коде" тоже может быть следствием какой-то другой более системной проблемы. Для того чтобы это выявить нужно просто задать вопрос "Почему?" Почему у нас много ошибок в коде?
<br />
И при ответе на эту группу вопросов можно выявить что:<br />
<ul>
<li> Много ошибок в коде ПОТОМУ ЧТО нет тестирования</li>
<li> Нет тестирования ПОТОМУ ЧТО не хватает времени</li>
<li> Не хватает времени ПОТОМУ ЧТО контракт заключен поздно.</li>
<li> Не хватает времени ПОТОМУ ЧТО неправильно оценен объем проекта до заключения контракта.</li>
<li> Неправильно оценен объем проекта ПОТОМУ ЧТО не существует готовых метрик.</li>
<li> Не существует готовых метрик ПОТОМУ ЧТО не проводится анализ проектов.</li>
</ul>
Ух ты, оказывается что проблема лежит вовсе не на стороне разработки, а закопана глубже, и лежит еще в области подготовки к заключению договора.<br />
Но ВАЖНО что на поверхности эти проблемы не лежали. И строя полную картинку<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgQ_45opm9V3ck-QgYt4j7DH8C3i9pKrE7QUcwLbTuh5Z6iPuk1nUMCgk6dKzRJM8UK6fs1_zCO7F2zCZQv5QobCkyqNLIlhZl5dO6rdYJ_MXhhgEePexhVB7px182QaKN_vAbU6Sr3Z_ri/s1600/toc-course-tree-1.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="640" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgQ_45opm9V3ck-QgYt4j7DH8C3i9pKrE7QUcwLbTuh5Z6iPuk1nUMCgk6dKzRJM8UK6fs1_zCO7F2zCZQv5QobCkyqNLIlhZl5dO6rdYJ_MXhhgEePexhVB7px182QaKN_vAbU6Sr3Z_ri/s640/toc-course-tree-1.png" width="516" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhX4h-O8C4R-DIVRqhHKE3SmHmH2y48I2II5I9kyX1pAeBU6TzHekjZtlAGu9U5MSV2rGfuyatAQvdhC8D7lW_STyrwRBs1yueeqcsqw-qgNvYI2IZLskyzE-ngBwfTxBzAX7ABKtxXNIU4/s1600/toc-course-tree-1.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><br /></a></div>
<br />
Можно найти ключевую проблему с которой и нужно применять изменения бизнес процессов. Данный пример короткий, но показывает что не все что лежит на поверхности действительно является ключевой проблемой. И при анализе состояния может выявиться еще 50 различных фактов влияющих на систему, а встраивая их всех в дерево причинно следственных связей и выявляя что является следствием а что причиной можно найти именно то самое ограничение системы которое нужно исправлять в первую очередь.
<br />
<h2>
Решаем проблемы </h2>
При разборе этого примера мы нашли что ключевой проблемой является отсутствие учета результатов ретроспектив, Для которых, хорошо было бы иметь какие-то артефакты проекта типа проектной документации. Да и результаты ретроспективы тоже имеет смысл оформлять в виде документа о выученных уроках.
<br />
И здесь мы можем прийти к конфликту.
<br />
Для того чтобы <i>делать проект быстро</i> мы должны экономить время, и соответственно не должны писать документов (Коммуникации важнее документации). Одновременно с этим мы должны д<i>умать о поддержке проекта и перспективах</i> развития поэтому мы должны писать документацию.
<br />
И здесь мы приходим к еще одному инструменту ТОС "Диаграмма Ключевого конфликта" или "грозовая туча", которая представляет собой маленькую схему показывающую не конфликтующие между собой условия достижения цели, но конфликтующие методы обеспечения условий.
<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiajwNpKUlv5IKEWIW6kuHOWNTzzlRFu1CdXE1O8HparDwUIEjNAPjfVtxya-hzhJhk4QqIGiYFY6v2dnft4odBna1uuQnjx7g_0db1U_mpw0TAxlIdG-HF3wN3U44mnzjzqQH3LJnGac1M/s1600/toc-conflict.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="124" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiajwNpKUlv5IKEWIW6kuHOWNTzzlRFu1CdXE1O8HparDwUIEjNAPjfVtxya-hzhJhk4QqIGiYFY6v2dnft4odBna1uuQnjx7g_0db1U_mpw0TAxlIdG-HF3wN3U44mnzjzqQH3LJnGac1M/s640/toc-conflict.png" width="640" /></a></div>
<br />
<br />
Для того чтобы решить эту "тучу" можно применить несколько различных методов<br />
<ul>
<li> мозговой штурм.
</li>
<li> теорию решения изобретательских задач. (ТРИЗ)</li>
<li> шесть шляп мышления</li>
</ul>
Или применить тот же самый логический подход, и выявить ложные предпосылки приводящие выбору методов обеспечения наших условий. Такак метод выбирается не только для обеспечения условия но на основании каких-то еще влияющих факторов. Иногда бывает что метод выбран правильно, но ошибка может крыться в условиях которые приводят к этим методам и тогда нужно поставить под сомнение сами условия приводящие к конфликту. Для этого тоже нужно исследовать предпосылки.<br />
Для выявления предпосылок применяется рассмотренное ранее <b>дерево текущей реальности</b>, которое мы достраиваем с использованием вопросов "Почему?" "Зачем?" и соответственно ответов а них "ПОТОМУ ЧТО..." и переводя из абстрактной плоскости "экономить время" в конкретную "сэкономить 20 часов" задавая вопросы "Сколько вешать в граммах?", "А в чем это выражается?" чтобы получить измеримые факты. (да-да критерии SMART)<br />
<ol>
<li> Экономия времени - Зачем? Сколько времени даст экономия? Есть ли другие способы экономии времени?</li>
<li> Долгая поддержка - Насколько долгая? Как часто меняются команды? Какой прогноз темпов развития? Есть ли другие способы обеспечения условия?</li>
<li> Не писать документацию - К чему это приведет? Какие будут нежелательные явления? Какие риски возрастут? Какой будет положительный эффект? Какие будут убытки?
</li>
<li> Писать документацию - Сколько это стоит? Сколько денег это принесет? Что для этого нужно? Какую именно документацию нужно писать? Как определить что это мы пишем а это не пишем?
</li>
</ol>
Прорабатывая каждую из этих веток можно выявить каике-то ложные предпосылки лежащие в основе условия или выбранного метода, которые могут быть ложными или исходят из более других корневых причин.
<br />
<h2>
Проверяем последствия </h2>
<br />
Если в результате анализа выявлено что наши условия действительно верные, но грозовая туча не решается, то можно проверить воздействия каждого из методов на систему в целом анализируя желательные эффекты (ЖЭ) и нежелательные явления (НЖЯ). Это можно проверить построив <b>дерево будущей реальности</b>:
<br />
Например:
<br />
Если мы будем писать документацию то
<br />
<ul>
<li> ЖЭ. У нас будет больше информации о принятии решений в будущем что повысит нашу стабильность выполнения работ.
</li>
<li> НЖЯ. Но одновременно с этим нужно будет тратить время на документирование
<ul>
<li> Но мы можем встроить документирование в процесс обдумывания проектных решений
<ul>
<li> ЖЭ. ТОГДА документы будут рождаться как побочный продукт и
</li>
<li> ЖЭ. Проектные решения будут лучше продуманы.
</li>
</ul>
</li>
</ul>
</li>
<li> НЖЯ. любой документ устаревает в момента написания
<ul>
<li> Описание на уровне свойств, характеристик и поведения без детализации снизит скорость устаревания
<ul>
<li> ЖЭ. Большая часть документов будут актуальны долгое время.
</li>
</ul>
</li>
</ul>
</li>
</ul>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgeG3OMuGnsDjeGLHqZo1AJEeMF5EaJKYUu_sCEq1q5TmYf4Vouh3816pBLcTr5eJ43vdk7fuDUCt5H9i1M8068Lzonm4jkwfOZZSYTV5D1RpJoqj_3WIWlVtTfzOJwGuAcYPl4qhbF_Qn8/s1600/toc-future-tree.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="308" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgeG3OMuGnsDjeGLHqZo1AJEeMF5EaJKYUu_sCEq1q5TmYf4Vouh3816pBLcTr5eJ43vdk7fuDUCt5H9i1M8068Lzonm4jkwfOZZSYTV5D1RpJoqj_3WIWlVtTfzOJwGuAcYPl4qhbF_Qn8/s640/toc-future-tree.png" width="640" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgeG3OMuGnsDjeGLHqZo1AJEeMF5EaJKYUu_sCEq1q5TmYf4Vouh3816pBLcTr5eJ43vdk7fuDUCt5H9i1M8068Lzonm4jkwfOZZSYTV5D1RpJoqj_3WIWlVtTfzOJwGuAcYPl4qhbF_Qn8/s1600/toc-future-tree.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><br /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjF6_IxdJ00G7CIFx66o1F1CdLaPiPamvZmssQJDkEEelI0KTAuMkcCnCriS1UgePWVOkS3aqu6iyn-Jp-Evu_Cavokj6kBenYdlGLA3at3GzogDRLp-HIcKaod697eOqBKys1zrpbOjbWd/s1600/toc-future-tree.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><br /></a></div>
<br />
Если мы НЕ будем писать документацию то
<br />
<ul>
<li>ЖЭ. мы сможем быстрее делать продукт
</li>
<li> НЖЯ. при смене разработчика вся информация уйдет с ним
</li>
<li> НЖЯ. Стоимость замены сотрудника возрастет
</li>
<li> НЖЯ. появляются непредсказуемые финансовые риски.
</li>
</ul>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhvfkFsAPzXAh5T7H9YwmM0oBMbPMjfdHTYx9V13x-SFqu2XFEuwpjxkBJXIShD8YJjTsKmfSuMIDh8WB_Vktv4DgYK7L7RPtgFQj2gZAfVX_8drKWddsTq-5t0QMVyuCLjaAcq16wc4QIJ/s1600/toc-future-tree-2.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="234" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhvfkFsAPzXAh5T7H9YwmM0oBMbPMjfdHTYx9V13x-SFqu2XFEuwpjxkBJXIShD8YJjTsKmfSuMIDh8WB_Vktv4DgYK7L7RPtgFQj2gZAfVX_8drKWddsTq-5t0QMVyuCLjaAcq16wc4QIJ/s640/toc-future-tree-2.png" width="640" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjF6_IxdJ00G7CIFx66o1F1CdLaPiPamvZmssQJDkEEelI0KTAuMkcCnCriS1UgePWVOkS3aqu6iyn-Jp-Evu_Cavokj6kBenYdlGLA3at3GzogDRLp-HIcKaod697eOqBKys1zrpbOjbWd/s1600/toc-future-tree.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><br /></a></div>
Оценка на уровне <b>дерева будущей реальности</b> последствий наших действий дает понимание о стоимости внедрения того или иного метода и всех нежелательных явлениях которые могут возникнуть в процессе внедрения.
Выбранное решение называется <b>"прорывом"</b> и оно влияет сразу на всю тучу. Решение может лежать и за пределами тучи и может быть найдено через методики мозгового штурма ТРИЗ и "шести шляп мышления".<br />
Воздействия на систему в процессе модулирования дерева называются "инъекциями".
Но полученное решение нужно будет проверить на логическом дереве с анализом последствий нашего воздействия на систему в целом. И решение о выбранном варианте можно проверить на предмет желательных эффектов и нежелательных явлений. И количество нежелательных явлений может сыграть существенную роль в выборе решения прорыва.
<br />
Данные методики также могут быть использованы и в оценке какой-то ситуации или при переговорах. Однако, при моделировании сценария вместо решения прорыва и инъекций можно использовать ваши действия с ответную реакцию оппонента которая может быть положительной (желательный эффект) и отрицательной (нежелательное явление).
<h2>Доклад</h2>
<iframe width="560" height="315" src="https://www.youtube.com/embed/gZBqGXW0zIc?list=PLNbnkNz7aLjYX84zWzL-5OXFnjEHSBdb0" frameborder="0" allowfullscreen></iframe>
<br />
<h2>
Что почитать по теме</h2>
<ul style="text-align: left;">
<li><a href="http://www.ozon.ru/context/detail/id/26994615/?partner=sbase" target="_blank"> Цель. Процесс непрерывного совершенствования. Элия М. Гольдратт, Джеф Кокс</a></li>
<li><div class="fn" itemprop="name">
<a href="http://www.ozon.ru/context/detail/id/4751669/?partner=sbase" target="_blank">Цель-2. Дело не в везенье. Джеф Кокс, Элия М. Гольдратт</a> </div>
</li>
<li><a href="http://www.ozon.ru/context/detail/id/5684817/?partner=sbase" target="_blank">Новая цель. Как объединить бережливое производство, шесть сигм и теорию ограничений. Джеф Кокс, Ди Джейкоб, Сьюзан Бергланд</a> </li>
<li><a href="http://www.ozon.ru/context/detail/id/5288956/?partner=sbase" target="_blank">Теория ограничений Голдратта. Системный подход к непрерывному совершенствованию. Уильям Деттмер</a></li>
</ul>
<br /></div>
</div>
Алексей Васильевhttp://www.blogger.com/profile/16557005870298289767noreply@blogger.com3tag:blogger.com,1999:blog-230361047938430358.post-85836444930343266742015-06-10T01:00:00.000-07:002015-06-29T14:53:13.918-07:00Притча об идеальном сотруднике<div dir="ltr" style="text-align: left;" trbidi="on">
Ученик пришел к Учителю и спросил<br />
— Учитель скажи, есть ли техники которые помогут мне выбрать правильного сотрудника который мне поможет вести компанию в будущее?<br />
<br />
— Никакая методика не поможет тебе - ответил Учитель<br />
<br />
— Но как же мне нанять идеального сотрудника?<br />
<br />
— Ты сможешь это понять только сердцем. Пришедший кандидат должен быть с тобой на одной волне. Если ты с ним на одной волне, значит он ускоряется когда ты ускоряешься, он замедляется когда ты замедляешься. Ты всегда знаешь чего хочет он, а он знает чего хочешь ты — ответил Учитель и сделал значительную паузу.<br />
<br />
— Но это же я сам! — воскликнул Ученик — Никто не может так чувствовать меня как я я сам!<br />
<br />
— Все правильно, — подтвердил Учитель — Ты не сможешь найти идеального кандидата, но ты сможешь найти что-то приближенное к нему. Однако помни, что если он будет повторять тебя то ты никогда не найдешь прорывного решения для твоей компании.<br />
<br />
— Так значит, мне нужно найти сотрудника который будет совсем не похожим на меня? — удивился Ученик.<br />
<br />
— Да, он должен быть совсем не похожим на тебя, но при этом быть с тобой на одной волне. — ответил Учитель<br />
<br />
— Но как же этого достигнуть? Это ведь не совместимые вещи - воскликнул Ученик, у которого в голове уже все начало путаться.<br />
<br />
— Ты сможешь понять это только сердцем — ответил Учитель тем же спокойным тоном и хитро улыбнулся.<br />
<br />
<br />
<br /></div>
Алексей Васильевhttp://www.blogger.com/profile/16557005870298289767noreply@blogger.com0tag:blogger.com,1999:blog-230361047938430358.post-46533461131502195732015-05-07T01:45:00.000-07:002015-06-29T14:54:06.892-07:00А что тут думать? И так понятно что делать.<div dir="ltr" style="text-align: left;" trbidi="on">
Выделю из комментария к <a href="http://cartmendum.livejournal.com/187227.html" target="_blank">посту</a> Макса Дорофеева <br />
<br />
Все хотят сэкономить время или просто аргументируют этим потому что процесс думания требует больше энергии, если <a href="http://www.rbcdaily.ru/autonews/562949979007835" target="_blank">«Мозг, имея массу не более 1,5—2% от массы тела, потребляет 25% всей энергии. "</a> в спокойном состоянии то что говорить о состоянии концентрации в процессе обдумывания решения? Наверное сжирает все 50% энергии.<br />
<br />
Но Человек, существу приспосабливаемое и хитрое, и инстинкты соответствующие выработались. Организм хочет сэкономить энергию, вдруг да саблезубый тигр нападет, "нам энергия еще пригодится". Вот и получается, что несмотря на то, что с одной стороны разум говорит что нужно концентрироваться на обдумывании задачи, а инстинкты говорят "не дергайся, выбери путь полегче". И конечно же сразу придумываются всякие отговорки типа "и так понятно что делать", потому что работа руками требует меньше энергии.<br />
<br />
Несколько примеров с натуры <br />
<br />
1.<br />
-- У меня есть идея и я ее сейчас буду делать.
<br />
-- А может ты ее сначала запишешь в вики?
<br />
-- А зачем? Она и так понятна. А я полдня описывать буду. Лучше я сразу нафигачу.
<br />
(через 2 дня)
<br />
-- Ну как , сделал?
<br />
-- Хм.. что-то я не учел, надо попробовать другой метод.
<br />
<br />
2.
<br />
-- Значит так, сначала делаешь тест и проверяешь вот этот кейс. Понятно?
<br />
-- Да.
<br />
(через полдня)
<br />
-- Ну как? Сделал?
<br />
-- Нет еще, что-то не получается.
<br />
-- Покажи?
<br />
(показывает на живой программе)
<br />
-- А почему ты на живой программе показываешь, ты что, тест не сделал?
<br />
-- Ну, мне показалось, что так будет быстрее.
<br />
<br />
<br />
Вывод, для того чтобы описать решение в вики нужно подумать "Как будет реализоваться?", а для того чтобы сделать тест нужно тоже подумать "Как будет использоваться", думать никто не любит. Каждому важнее покодировать это более интересное занятие чем какое-то абстрактное думание. Тут включил - работает или не работает, как в детском конструкторе. Собирать в голове головоломку это уже другой уровень. А у человека инстинкт поменьше нагружать себя, не думать, экономить энергию, быть проще.. <strike>и быть поближе к животным.</strike><br />
<br /></div>
Алексей Васильевhttp://www.blogger.com/profile/16557005870298289767noreply@blogger.com1tag:blogger.com,1999:blog-230361047938430358.post-81358088302479761802015-03-02T11:53:00.001-08:002015-06-29T14:54:43.664-07:00Тезисно по моему докладу на ITGlobalMeetup#4: TOC на Agile проектах.<div dir="ltr" style="text-align: left;" trbidi="on">
Для тех кто заинтересовался применением критической цепи для проектах
по разработке ПО (Agile, XP, иные) я выложу здесь основные тезисы:<br />
<br />
<ol style="text-align: left;">
<li>Метрики
в XP и SCRUM такие как скорость реализации задач и диаграмма сгорания
показывают только ДАТУ когда проект будет завершен но не говорят когда
надо договариваться.</li>
<li>В голове заказчика все-равно есть бюджет и расписание, даже если вы продаете по Time&Materials. И он не всегда обрадуется увеличению сроков и бюджета в последний момент.</li>
<li>Все задачи на проекте можно представить в виде последовательности - критической цепи.</li>
<li>Для критической цепи можно зарезервировать буфер проекта, обычно 1/2 от расчетной длительности проекта.</li>
<li>Контролируя
расход буфера можно принять решение о необходимости внесения изменений в
план и расписание проекта и необходимости идти к заказчику.</li>
</ol>
<br />
Это может выглядеть так:<br />
<br />
<a name='more'></a><br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiq_q0AeQmo7tmaXLrt9uDGsYysh2IbqatCSWNN77ScXKdyvN2yeurmpVaBKsVFIIXq82bpsc1uF7Nay9qWF0TfgOrqvn646yMAJN49qwoasb4WtbiY5HPVjOol_r76TDhn23STfYEa8XxH/s1600/buffers.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="229" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiq_q0AeQmo7tmaXLrt9uDGsYysh2IbqatCSWNN77ScXKdyvN2yeurmpVaBKsVFIIXq82bpsc1uF7Nay9qWF0TfgOrqvn646yMAJN49qwoasb4WtbiY5HPVjOol_r76TDhn23STfYEa8XxH/s1600/buffers.png" width="320" /></a></div>
по вертикали - % расхода буфера, по горизонтали - % расхода расписания <br />
<br />
или так:<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEipQZlmvkPzAaJ41t-kd_Y6DybA4_klzE7X5dy0HrItIftQ0MfApIZfST-y5O7wQttHirlt-2E0uMnKq8ABd41Ux9ytjoVF4EWJKzdcV9Z0MO1fdUFNRgV051L-zNzkcMTiTHFsE2I67ZaL/s1600/buffer-line.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="24" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEipQZlmvkPzAaJ41t-kd_Y6DybA4_klzE7X5dy0HrItIftQ0MfApIZfST-y5O7wQttHirlt-2E0uMnKq8ABd41Ux9ytjoVF4EWJKzdcV9Z0MO1fdUFNRgV051L-zNzkcMTiTHFsE2I67ZaL/s1600/buffer-line.png" width="640" /></a></div>
<br />
Значения цветов:<br />
<ul style="text-align: left;">
<li> Мы в зеленой зоне - все идет по плану</li>
<li>В желтой зоне - готовь план изменений (увеличение команды, изменение объемов или расписания или иное)</li>
<li>В красной зоне - применяй план изменений, иди к заказчику.</li>
</ul>
Чем раньше Заказчику узнает о проблемах , тем проще будет договориться.<br />
<br />
<br />
Кратко из вопросов:<br />
<br />
<b>Когда меняется буфер проекта? </b><br />
<br />
В начале проекта и при изменении плана проекта, то есть если вы договорились об изменении объема или сроков, то меняете буфер.<br />
<br />
<b>Имеет ли смысл применять буфера на проектах в случае, когда не владеешь ресурсом</b>?<br />
<br />
Для того чтобы вовремя узнать о проблемах на проекте имеет смысл всегда применять.Также состояние буфера можно использовать как критерий в переговорах о выделении ресурсов.<br />
<br />
<b>Как часто проверять состояние буфера?</b><br />
<br />
В идеале каждый день, но каждый день у вас задачки не завершаются. Поэтому, целесообразно, соотнести со средней скоростью закрытия задач. например раз в неделю.<br />
<br />
<br />
<b>Какие есть инструменты по учету буферов?</b><br />
<ol style="text-align: left;">
<li>Насколько я слышал есть модуль CCPM к MSProject</li>
<li>У меня есть свой инструмент. Прогноз на основе скорости рассчитывает <a href="http://bipulse.ru/" target="_blank">Пульс</a> на сайте. Версия которая учитывает буфера критической цепи есть но не выложена, пишите если интересно.</li>
</ol>
<br />
<br />
<br />
<br />
<br /></div>
Алексей Васильевhttp://www.blogger.com/profile/16557005870298289767noreply@blogger.com0tag:blogger.com,1999:blog-230361047938430358.post-53048252621342080712015-03-02T11:52:00.001-08:002015-06-29T14:55:17.479-07:00по следам ITGlobalMeetup #4<div dir="ltr" style="text-align: left;" trbidi="on">
Для меня, наверное, самое важно было - это выступить. Поэтому я даже себе программу не придумал, что я буду делать после выступления. Все люди как люди, заранее распланировали, куда идти и что смотреть. А я как-то завис. В итоге получилось, что послушал в основном про бизнес анализ. <br />
<br />
<ul style="text-align: left;">
<li>Семена Петкова про Пользовательские и истории и бумажное прототипирование. </li>
<li>Евгению Чучмакову про Формирование требований в виде вариантов использования.</li>
</ul>
Что в целом, мне кажется, про одно и тоже только с применением разных техник. На разных уровнях, требуются разные техники.<br />
<br />
Там где перестают отрабатывать варианты использования можно переходить к применению бумажного прототипирования.<br />
<br />
Из хорошего:<br />
<ul style="text-align: left;">
<li>Выступление, мне кажется, удалось. </li>
<li>Нашел много новых друзей.</li>
</ul>
Из не очень хорошего:<br />
<ul style="text-align: left;">
<li>Футболка мне не досталось, когда я собрался ее получить их уже не было %(.</li>
<li>Домой в одиночестве ехал. Точно никому на ЮЗ не нужно было?</li>
</ul>
</div>
Алексей Васильевhttp://www.blogger.com/profile/16557005870298289767noreply@blogger.com0tag:blogger.com,1999:blog-230361047938430358.post-37386883272684825612015-02-22T12:52:00.000-08:002015-06-29T14:56:11.831-07:00Экспресс-курс «Проектное планирование» <div dir="ltr" style="text-align: left;" trbidi="on">
Везде ли применимо проектное планирование?<br />
Любую деятельность компании или отдельного человека можно разделить на два состояния:<br />
<br />
<ol>
<li> Я делаю (сделаю) что-то сейчас; </li>
<li> Я буду это делать в будущем.</li>
</ol>
<br />
Первое состояние очень популярно в торгово-закупочной деятельности: <br />
<br />
<ul>
<li> купить <b>прямо сейчас</b>;</li>
<li> заказать <b>прямо сейчас</b>;</li>
<li> позвонить <b>прямо сейчас</b>.</li>
</ul>
<br />
На вас сваливается десяток задач которые надо сделать <b>прямо сейчас</b>. Как правило, это задачи на «на пять минут», хотя иногда подготовка к выполнению самой задачи может занять и больше пары часов. Если такое происходит, тогда весь поток задач, которые надо сделать «прямо сейчас», останавливается, пока <b>короткая</b> задача не будет завершена, Однако, каким-то мифическим образом все такие задачи «рассасываются» к концу недели.<br />
<br />
<a name='more'></a><br />
<a href="https://www.blogger.com/null" name="habracut"></a><br />
Деятельность, в которой присутствуют задачи появляющиеся «прямо сейчас» и которые нужно сделать «прямо сейчас» или «сегодня», невозможно планировать, она зависит исключительно от внешних факторов воздействия и носит краткосрочный характер. Единственное, что при таком подходе применимо — это <b>регистрация</b> задачи и её результатов, чтобы её можно было перепоручить или поднять историю при возникновении спорных моментов или оценки эффективности работы исполнителя.<br />
<br />
Другое состояние относится к планированию своей деятельности или деятельности команды, компании. Если при приходе задачи вы ее откладываете с формулировочкой «Я буду делать это в будущем», то сразу напрашивается вопрос: <b>В «будущем» это когда?</b><br />
<br />
Если ваша очередь задач пустая, то «будущее» для выполнения новой работы может наступить прямо сейчас, но что будет если очереди уже десяток отложенных на будущее задач? <br />
<br />
Она добавится в хвост очереди? А если её приоритет между пятой и шестой задачами? Хорошо, если никто не спрашивает вас: «когда ты сделаешь мою задачу?», то тогда можно просто поставить её очередь и продолжать заниматься текущей работой. <br />
<br />
Если ваша очередь задач держится в пределах десятка, значит вас можно поздравить, скорость прихода новой работы и скорость ее выполнения у вас примерно одинаковая, и что-то менять в этой системе и заниматься планированием вам не требуется.<br />
<br />
Возьмем другую ситуацию, вам приносят задачу и постановщик передавая её интересуется «Когда ты её сделаешь?». тогда появляются сразу два вопроса:<br />
<br />
<ol>
<li> Сколько времени нужно потратить на выполнение задачи?</li>
<li> Когда сможете приступить к выполнению задачи?</li>
</ol>
<br />
от ответов на которые зависит ответ на самый важный вопрос «Когда ты её сделаешь?».<br />
Как только вы начнете пытаться отвечать на подобные вопросы, то вас можно поздравить, вы подошли к необходимости планировать свою деятельность.<br />
<br />
<h4>
С чего начинается планирование</h4>
<br />
Самый простой план это список задач:<br />
<br />
<ul>
<li> Задача 1 </li>
<li> Задача 2</li>
<li> Задача 3</li>
</ul>
<br />
Сегодня вы делаете первую задачу, сдвигаете список вверх, делаете вторую потом также третью. На вопрос «ты когда сделаешь мою задачу» которую вы поставили в конец списка можно показать список и сказать «Когда я закончу все эти, тогда с могу сделать и твою задачу».<br />
<br />
Подход хороший, можно всем заявить «Я планирую свою деятельность!», но будет ли доволен постановщик задачи таким ответом? <br />
<br />
Думаю, что за неимением других вариантов ему <b>придётся</b> довольствоваться таким. Но, на самом деле он хочет услышать примерную дату когда будет завершена его задача.<br />
<br />
Этот подход часто применяется людьми которым важно только то, чем они занимаются только сейчас, по концепции «живи сегодняшним днём, незачем забивать голову всякой менеджерской пургой». И в результате, постановщик задачи обещая кому-то какие-либо сроки просто называет цифры с потолка и скрещивает пальцы надеясь на «авось успеют».<br />
<br />
Если постановщик задачи более дотошный, то он вас сможет принудить сказать какую-то цифру оценки сроков, которую вы конечно же возьмете «с потолка» опираясь на свой опыт решения похожих задач. <br />
<br />
И конечно же промахнетесь, примерно в два, три раза. И когда постановщик придёт к вам со словами «Ну как же так, Василий, ты же обещал и не успел. Ты меня подставляешь.» вы будете чувствовать себя виноватым, хотя, и вы и пришедший оба осознают что цифры были взяты с потолка.<br />
<br />
Виноватым никто не любит себя чувствовать, виноватостью можно манипулировать. И когда вам захочется, чтобы в следующий раз такого не повторилось, возможны два варианта:<br />
<br />
<ol>
<li> При запросе срока выполнения спрятаться за формулировкой «я не знаю», «после тех что в списке», или</li>
<li> Подумать, как улучшить качество оценки трудоемкости того чего делать еще не приходилось.</li>
</ol>
<br />
Если вы выберете второй путь, то поздравляю, у вас появилась потребность в планировании своей деятельности.<br />
<br />
<h4>
Составляем план, оцениваем сроки </h4>
<br />
Потребность в планировании деятельности есть, но как её реализовать? Делаем план! <br />
План, это записанные наши предположения относительно того:<br />
<br />
<ul>
<li> что нужно делать; </li>
<li> как делать; </li>
<li> сколько времени это <i>предположительно</i> займет и </li>
<li> кто будет делать.</li>
</ul>
<br />
Почему именно <i>«предположительно»</i>? Потому, что между тем, как вы запишете в задаче что нужно делать и кто ее будет делать может произойти тысяча всевозможных событий влияющих на ваш план и на предполагаемого исполнителя.<br />
<br />
Например: он может внезапно заболеть, его может переехать автобус (см. автобусный фактор), заказчик внезапно решил отказаться от данной работы, правительство издало закон требующий лицензирования вашей деятельности, другая компания выпустила продукт упрощающий выполнение вашей работы, вам выделили дополнительные ресурсы. Каждый из этих маленьких моментов может как увеличить сроки выполнения работы так и уменьшить её объемы.<br />
<br />
В самом оптимистичном сценарии мы можем <i>предполагать</i> что эти события не произойдут. И тогда мы можем построить план:<br />
<br />
<ul>
<li> Задача 1, ожидаемый срок выполнения 3 дня, выполняет Василий;</li>
<li> Задача 2, ожидаемый срок выполнения 4 дня, выполняет Петр;</li>
<li> Задача 3, ожидаемый срок выполнения 2 дня, выполняет Виктор.</li>
</ul>
<br />
Наши ожидания составят 9 человеко/дней на 3-х человек, и весь план может быть выполнен <b>предположительно</b> за 4 дня.<br />
<br />
Когда команда дружно начинает делать работу, оказывается что:<br />
<br />
<ul>
<li> Василий не знает специфики работы и постоянно спрашивает Петра (+2 дня, итого 5 дней);</li>
<li> Петру приходится отвлекаться от своей задачи и объяснять Василию основную идею его задачи, но он профессионал и поэтому уложился раньше запланированного срока (3 дня);</li>
<li> Виктор нашел что можно снизить риски в будущем, и для этого потратил дополнительно 2 дня на решение дополнительной задачи (+2 дня, итого 4 дня);</li>
</ul>
<br />
В итоге, реализация плана вместо ожидаемых 9 человеко/дней заняла 12 дней (5 + 3 + 4), то есть, мы промахнулись с оценкой на 3 дня, и фактически объем работы увеличился на 30% от планируемого. Однако по календарю это заняло 5 календарных дней, это означает, что следующая работа не будет начала раньше понедельника следующей недели, что приводит к увеличению сроков на 75% (7 дней вместо 4).<br />
<br />
Если на основе вашего плана, вы пообещали какие-то сроки постановщику задачи, то опять возникнет ситуация когда вас будут обвинять " Ты же обещал, и не выполнил."<br />
<br />
И тут опять есть два пути:<br />
<br />
<ul>
<li> Первый, откатиться на предыдущие позиции со словами «А что толку оценивать, все-равно оценки не сбудутся/не верны.», или </li>
<li> Второй, научиться учитывать разницу между запланированными объемами и сроками и фактически потраченными ресурсами и временем при планировании новой работы.</li>
</ul>
<br />
Если выбираете второй путь, то примите поздравления, у вас есть необходимость в оценке рисков.<br />
<br />
<h4>
Улучшаем план </h4>
<br />
В предыдущем разделе запланированный объем и сроки увеличились из-за двух факторов:<br />
<br />
<ul>
<li> оценка объема как правило сильно оптимистичная;</li>
<li> сработали неучтенные риски.</li>
</ul>
<br />
Человеку свойственно всегда давать оптимистичные оценки по времени, особенно когда постановщик задачи ожидает услышать сроки поменьше. Или же при оценке объема работы учитывается только личный опыт выполнения похожей задачи и не учитывается опыт фактического исполнителя.<br />
<br />
При быстрой оценке объемов работы в большей части случаев риски не учитываются совсем. Риски бывают разные, бывают такие, которые требуют немного больше времени на устранение, а бывают такие, которые могут похоронить ваш проект.<br />
<br />
На ход исполнения проекта в основном влияет относительно небольшой набор рисков, которые наступают регулярно, но их постоянно забывают учитывать.<br />
<br />
Я приведу несколько из них, с которыми сталкивается каждый:<br />
<br />
<ul>
<li> Риск доступности ресурсов — Петр который был нужен Василию очень занят в этот момент, поэтому Василию пришлось ждать;</li>
<li> Риск неполноты оценки задачи — при оценке задачи не были учтены все факторы влияющие на её исполнение;</li>
<li> Риски квалификации исполнителя — оценка давалась с точки зрения выполнения её экспертом, а фактически её выполнял начинающий что привело к затратам на обучение.</li>
</ul>
<br />
Все эти риски можно свести к одному: Риск точности оценки планирования. Учет этого риска можно выразить в виде <i>«коэффициента точности планирования»</i>. Если принять во внимание, что:<br />
<br />
<ol>
<li> принципы оценки объемов работы меняются редко,</li>
<li> команда выполняющая проект меняется редко и </li>
<li> характер выполняемой работы не меняется, </li>
</ol>
<br />
То, полученные расчеты коэффициента за предыдущий этап работ или предыдущий проект можно учитывать при расчете плана нового проекта или этапа работ.<br />
<br />
Коэффициент точности планирования рассчитывается на основе истории выполненных работ, как отношение запланированного времени к фактически затраченному времени.<br />
<br />
<pre> плановый_объем
коэфф_точности = --------------------
фактические_затраты
</pre>
<br />
здесь:<br />
<i>плановый_объем</i> — объем работы в человеко-днях<br />
<i>фактические_затраты</i> — затраты в календарных человеко-днях.<br />
<br />
Учёт коэффициента точности планирования для оценки запланированного объема работ позволяет более точную дату завершения работы. <br />
Однако если вы просто выполните расчет с учетом коэффициента точности планирования это будет тоже <i>оптимистичная</i> оценка прогноза, она не учитывает наступление самого важного риска: увеличение объема работ из-за неполноты проработки задачи.<br />
Для того чтобы его рассчитать необходимо оценить насколько вырос начальный объем работ относительно фактически выполненного:<br />
<br />
<pre> фактический_объем
коэфф_увеличения_объема = --------------------
начальный_объем
</pre>
<br />
<br />
здесь:<br />
<i>фактический_объем</i> — объем работы на конец проекта или этапа работ в запланированных человеко-днях.<br />
<i>начальный_объем</i> — объем работы на начало проекта или этапа работ в запланированных человеко-днях.<br />
<br />
Сам по себе коэффициент увеличения объема работ является величиной статической, однако если мы примем во внимание, что тенденция к увеличению объема сохранится в дальнейшем, то его необходимо учитывать, как влияющий фактор.<br />
<br />
Таким образом, наиболее вероятный срок завершения работы должен учитывать: начальный объем, коэффициент точности планирования и коэффициент увеличения объема работы. Такой такой срок назовем <b>«пессимистичным»</b>.<br />
<br />
Формула получится такая:<br />
<br />
<pre> начальный_объем
календарный_срок = ----------------------------- x коэфф_увеличения_объема x неделя
коэфф_точности x команда
</pre>
<br />
где:<br />
<i>начальный_объем </i> — начальный объем работы в человеко/днях<br />
<i>коэфф_точности </i> — коэффициент точности планирования<br />
<i>коэфф_увеличения_объема</i> — коэффициент увеличения объема работы<br />
<i>неделя</i> — отношение календарных дней к рабочим в неделю, равно 7/5 <br />
<i>команда</i> — количество исполнителей<br />
<br />
Таким образом наш пример из предыдущего раздела будет иметь следующую раскладку:<br />
<br />
<ul>
<li> ожидаемый план — 9 чел/дней;</li>
<li> дополнительная работа — 2 дня;</li>
<li> иные риски — 2 дня;</li>
<li> фактически потратили: 12 чел/дней;</li>
<li> потраченные дни на выполнение начального плана: 10 чел/дней;</li>
<li> коэффициент точности планирования: 9/10 = 0.9;</li>
<li> коэффициент увеличения объема: 12/9 = 1.33.</li>
</ul>
<br />
<br />
Если вернемся назад и сделаем прогноз срока завершения, то получим:<br />
<pre> 9
календарный_срок = --------- x 1.33 x 1.4 = 6.2 календарных дня
0.9 x 3
</pre>
<br />
Таким образом, наш прогноз показал, что работа займёт неделю.<br />
<br />
Если истории выполненных работ у проекта нет, то при прогнозе негативного сценария имеет смысл в качестве рисков на увеличение объема брать 50% объема, то есть коэффициент будет равным 1.5.<br />
<br />
Таким образом, при прогнозировании сроков завершения проекта с учетом основных рисков прогноз может быть <i>оптимистичный</i>, без учета увеличения объема работы и <i>пессимистичный</i> с учетом тенденции к росту объема запланированной работы.<br />
<br />
<h4>
Ресурсы те же, проекты увеличиваются </h4>
<br />
Итак, вы уже научились выполнять оценку наиболее вероятной даты завершения этапа работ. Но количество проектов начинает увеличиваться и за одного и того же исполнителя начинается конкуренция между проектами.<br />
<br />
Становится необходимым ставить проекты в очередь и смещать дату начала работ, пока нужный сотрудник не освободится. Например, есть веб-студия, и все держится на одном классном дизайнере, к нам приходит клиент и мы уже готовы утвердить контракт, но встает вопрос «Какие сроки обещать клиенту?», который зависит от ответа на вопрос «Когда освободится дизайнер?»<br />
<br />
В нашем случае, дизайнер является <i>ограничением</i> всей системы.<br />
<br />
Для того, чтобы ответить на вопрос о доступности дизайнера, необходимо рассчитать для него оптимистичный и пессимистичный прогноз — также, как это делается для этапа работ, но с учётом индивидуального плана задач, в который входят задачи всех выполняемых проектов.<br />
<br />
<h4>
Что по почитать по теме</h4>
<br />
<ul>
<li> «Экстремальное программирование: планирование» Кент Бек, Мартин Фаулер;</li>
<li> Подвижная мишень и дрожащие руки. Максим Дорофеев (слайдкаст);</li>
<li>«Вовремя и в рамках бюджета. Управление проектами по методу критической цепи» Лоуренс Лич;</li>
<li> Теория ограничений.</li>
</ul>
<div dir="ltr" style="text-align: left;" trbidi="on">
<br />
Ремарка: люблю чтобы было все в одном месте. Статья была опубликована на хабре 18.11.2014. </div>
<ul>
</ul>
</div>
Алексей Васильевhttp://www.blogger.com/profile/16557005870298289767noreply@blogger.com0tag:blogger.com,1999:blog-230361047938430358.post-56540778781027266902015-02-19T12:51:00.000-08:002015-06-29T14:56:26.352-07:00О внутренних конфликтах<div dir="ltr" style="text-align: left;" trbidi="on">
Вытащу отдельно из обсуждения в блоге <a href="http://cartmendum.livejournal.com/177440.html" target="_blank">Макса Дорофеева</a>. <br />
<br />
<br />
Внутренний конфликт интересов приводит перенапряжению и как следствие состоянию "задолбанности" или попытке сбежать от действий которые требуют какой-то полезной активности.<br />
<br />
Но откуда он получается?<br />
<h2 style="text-align: left;">
<a name='more'></a> Пьеса, в двух частях. </h2>
<br />
<div style="text-align: right;">
<pre><i>Меня сегодня Муза посетила,
Посетила, так, немного посидела и ушла...</i></pre>
<pre><i>Она ушла, исчезло вдохновенье
И три рубля, должно быть, на такси.</i></pre>
</div>
<br />
Действующие лица живут в голове:<br />
<br />
<b>Мысль</b> - самая сильная из всех других мыслей, она всех остальных вытесняет, поэтому она одна, неповториямая.<br />
<b><br /></b>
<b>Здравый смысл</b> - он же Совесть, логика, давление внешних обязательств,<br />
<br />
<b>Мозг</b> - он не живет, он просто есть, и только он может что-то делать. А все остальные могут только советовать ему что делать. То есть единственный копатель в этом зоопарке.<br />
<br />
<h3 style="text-align: left;">
<b>Часть 1. Утро рабочего дня</b>. </h3>
<br />
<b>Мысль: </b>Бежим туда, там много интересного, надо быстро что-то делать пока без нас все не сделали, нам же ничего не достанется!<br />
<br />
<b>Здравый
смысл: </b>Не, Мысль, постой мы так не договаривались, у нас сейчас что?
Правильно, рабочий день поэтому давай позови Мозг, будем работу
работать.<br />
<br />
<b>Мозг: </b>что-то я не врубаюсь что сделать делать надо, как-то все сложно и запутано. А я какой-то не выспавшийся сегодня.<br />
<br />
<b>Мысль:</b> Во, Смысл, слышишь? Мозг работать не хочет. Давай бежим туда, без нас всё сделают, перспективы потеряем!<br />
<br />
<b>Здравый
смысл:</b> Мысль, стой! Я же тебе русским языком объясняю, тебе не платят
за то что ты там бегаешь по своим делам. Эй мозг, давай уже включайся, а
то мы без обеда останемся.<br />
<br />
<b>Мозг: </b>ну ладно, сейчас включусь. Где у меня тут был интернет с котиками?..<br />
<br />
<b><b>Здравый
смысл</b>:</b> Начал работать, ну вот и хорошо, а я пока отдохну.<br />
<br />
<h3 style="text-align: left;">
<b>Часть 2. Вечер рабочего дня</b></h3>
<br />
<b>Здравый смысл:</b> Мозг, ау? А что ты сделал то за сегодня? <br />
<br />
<b>Мозг:</b> ну я , как бы это, типа работал, как ты и хотел.<br />
<br />
<b>Здравый Смысл: </b>Хотеть, то, я хотел, а что-то я вижу что завтра нам кушать будет нечего.<br />
<br />
<b>Мысль: </b>А я вас уговаривала, уговаривала. Лучше, бы меня послушались я бы, я бы...<br />
<br />
Занавес.<br />
<br />
<br />
В этом случае мозг выключился. Но что было бы если он стал пытаться делать что ему говорит Здравый смысл?<br />
<br />
<b>Мозг: </b>таак.. , надо подумать..<br />
<br />
<b>Мысль: </b>Мозг, смотри сюда, вот видишь воон то решение? Давай бежим туда, без нас все сделают.<br />
<br />
<b>Мозг: </b>Отстань, Мысль! Таак.. , надо подумать.. как тут лучше...<br />
<br />
<br />
<b>Мысль: </b>Мозг, бросай всё, бежим быстрее, без нас все сделают.<br />
<br />
и так до вечера.<br />
<b><br /></b>
А вечером выясняется что работа выполнена на 5 процентов , а задолбанность как будто-то молотом махал. <br />
<br />
<h4 style="text-align: left;">
Результат:</h4>
<br />
Если Мысль совпадает со Здравым Смыслом то все хорошо, если они начинают тянуть в разные стороны, то тут все зависит от того кто выиграет. Но если выиграет Смысл, и даже Мозг будет готов это делать и не уйдет в интернет, то вечером Мозг будет задолбан Мыслью.<br />
<br />
Потому что Здравый Смысл , можно заглушить, а вот Мысль хрен заглушишь. Поэтому важно сначала убедить Мысль что то что она хочет не сильно важно прямо сейчас, и постараться ее заменить на другую, а уж потом нагружать Мозг работой.<br />
<br />
<br />
Коллеги, какой ваш способ борьбы с таким внутренним конфликтом?<br />
<br />
<br /></div>
Алексей Васильевhttp://www.blogger.com/profile/16557005870298289767noreply@blogger.com2tag:blogger.com,1999:blog-230361047938430358.post-87971046229989884012015-02-18T02:40:00.001-08:002015-02-18T02:40:51.523-08:00Предисловие<div dir="ltr" style="text-align: left;" trbidi="on">
В связи с безвременной кончиной Я.Ру где я заводил предыдущий свой технический блог и необходимостью что-то рассказать про свои практики управления проектами и какие-то технические решения из области <strike>фантастики</strike> разработки ПО, я столкнулся с тем что спамить свой <a href="http://sbase.livejournal.com/" target="_blank">ЖЖ</a> техническими постами как-то нехорошо.<br />
<br />
Однако, мысль которую я хочу рассказать не совсем подходит, с моей точки зрения, по качеству для публикации на <a href="http://habrahabr.ru/users/sbase/topics/" target="_blank">Хабре</a> или <a href="http://megamozg.ru/users/sbase/topics/" target="_blank">Мегамозге</a>. А <a href="https://plus.google.com/u/0/105266763934862052185/posts" target="_blank">гуглоплюс</a> категорично не годится для нормальных постов с обсуждениями.<br />
<br />
Вот именно такие заметки я и будут размещать здесь.<br />
<br />
<br /></div>
Алексей Васильевhttp://www.blogger.com/profile/16557005870298289767noreply@blogger.com0