Декларация взаимозависимости для современного менеджмента – The declaration of interdependence for modern management or DOI
| March 30, 2012 | Posted by admin under Методологии, Практики, Статьи |
Автор: Alistair Cockburn
http://alistair.cockburn.us/The+declaration+of+interdependence+for+modern+management+or+DOI
Декларация взаимозависимости (Declaration of interdependence, DOI) управления проектом/продуктом была написана в 2005 году как дополнение к Agile Manifesto. См. также:
DOI в журнале Better Software
Подытоживаем DOI (дискуссия: Re: Summarizing the DOI)
The Declaration of Interdependence DOI 060.ppt
(ранний логотип) Pmdoilogo.gif
Вот пояснение, которое я написал сразу после создания DOI
“Мы..
увеличиваем возврат инвестиций за счет того, что — фокусируемся на постоянном потоке ценности.
поставляем надежные результаты за счет того, что — привлекаем заказчиков к постоянному взаимодействию и делаем их участниками процесса разработки.
готовы к неопределенности и можем справиться с ней — используя итерации, прогнозирование и адаптацию.
проявляем творчество и инновационные подходы за счет того, что — признаем личность непосредственным источником получения ценного результата (пользы), и создаем условия, в которых люди могут себя проявить, изменить что-то к лучшему.
повышаем производительность путем — групповой ответственности за результаты и общей ответственности за эффективность команды.
повышаем эффективность и надежность за счет — выбранных по ситуации стратегий, процессов и практик.”
Написано в 2005 году: David Anderson, Sanjiv Augustine, Christopher Avery, Alistair Cockburn, Mike Cohn, Doug DeCarlo, Donna Fitzgerald, Jim Highsmith, Ole Jepsen, Lowell Lindstrom, Todd Little, Kent McDonald, Pollyanna Pixton, Preston Smith и Robert Wysocki.
“Декларация взаимозависимости” для современного (agile/адаптивного) управления (продуктом/проектом)
Как менеджеру реализовать agile разработку, принимая во внимание команду и высшее руководство? Что если менеджер продукта (не проекта) хочет использовать идеи agile разработки для чего-то отличного от создания ПО? Как насчет тех руководителей, которые хотят скорректировать и улучшить правила поведения управленческих команд в организации, придерживаясь лучших идей бизнеса, и им совершенно не интересен термин “agile” и создание ПО. Как насчет самоуправляемых команд, в которых не задана роль Менеджер? Что должны сказать об этом современные менеджеры проектов, и научились ли чему-нибудь они/мы за последние годы использования практик agile?
В продолжение встречи, на которой был подписан agile manifesto в 2001 году, группа известных людей, которые занимаются тематикой управления проектами, включая (в обратном алфавитном порядке):
Robert Wysocki (”Effective Project Management”),
Preston Smith (”Rapid Product Development”),
Pollyanna Pixton,
Kent McDonald,
Todd Little (Conference Director, Agile Development Conference),
Lowell Lindstrom,
Ole Jepsen (Founder, Danish Agile Development Group),
Jim Highsmith (”Agile Project Management”),
Donna Fitzgerald (Co-founder, American Society for the Advancement of Project Management),
Doug DeCarlo,
Mike Cohn,
Alistair Cockburn (”Agile Software Development”),
Christopher Avery (”Teamwork is an Individual Skill”),
Sanjiv Augustine (”Managing Agile Projects”),
David Anderson (”Agile Management for Software Engineering”)
собралась вместе, чтобы обсудить правила для современной парадигмы проекта, проектного и общего управления. Не для того, чтобы придумать новое слово, а работая над шестью правилами управления, группа написала то, что называется “Декларация взаимозависимости” для современного управления проектом и продуктом.
Для этого есть даже логотип ;-). Представьте шестиугольник (графитовое кольцо или гайку) , на которой почасовой стрелке сверху вниз отмечены Ценность (Value) – Личности (Individuals) – Команды (Teams) – Неопределенность (Uncertainty) – Ситуации/Контекст (Situations / Context)- Заказчики (Customers) – (ok, это простое перечисление; будем ждать художников, которые сделают это красиво)
Предположительно будет web site, с хорошим названием и организацией, в которую можно обратиться, но основным продуктом этой встречи стал набор из шести руководящих принципов, которые подходят для управления проектами и продуктами. Группа продолжает работать над услугами, которые сможет предоставлять поддерживающая организация, и над тем, как к этому могут присоединиться другие люди, принять участие и внести свой вклад в общее дело. Ниже – мои размышления об этой важной декларации.
Конечно имейте в виду, что это моя личная интерпретация и экстраполяция Декларации. У других авторов будет своя.
1. Структура Декларации
Предложения сформированы из двух частей, Мы реализуем X —- делая Y. Т.е. Y – это то, что мы делаем,чтобы добиться X. Мне показалось легче читать это в формате двух колонок, где левая колонка определяет то, что мы надеемся реализовать, а правая колонка определяет как мы намерены это реализовать. Давайте посмотрим на декларацию в такой форме:
| Достичь: | С помощью: | И… |
| увеличение ROI | сфокусироваться на “потоке ценности” (например, не на “отслеживании прикладываемых усилий”). | постоянный (непрерывный) поток, предпочтительно |
| надежные результаты | приобщать заказчика к постоянным взаимодействиям | вовлеченность |
| творчество и инновации | признавать каждого человека (личность) непосредственным источником получения ценного результата (пользы); | создавать условия, в которых люди могут проявить себя, изменить что-то к лучшему. |
| управление неопределенностью | итерации, | прогнозирование и адаптация (т.е., думать о будущем, планировать, делать итерации, поставлять, размышлять, адаптировать). |
| эффективность и надежность | выбранные по ситуации стратегии, процессы и практики. (т.е., никто не говорит: “ребята, привыкайте”) | |
| увеличенная производительность | ответственность всей группы за результат (т.е., вся группа отвечает как единое целое, никого конкретно не обвиняют); | общая ответственность за эффективность команды. |
2. Что это дает управлению “проектами”?
Многие из вас заметят, что в Декларации мало что уникально для управления “проектами”. В основном это касается менеджмента в целом. Декларация понравилась моим друзьям, преподавателям и коучам менеджмента (например, в MBA школах). Наверное, она должна называться просто ”Декларация взаимозависимости современного менеджмента”?
(Могу сказать, что лично я не думал об этом как об “менеджменте вообще”, когда участвовал в создании —для меня это были следующие три пункта:
Люди – их сердца и умы; а также их глаза, уши и рты (общение: общая игра, помните?)
Специфичные для ситуации стратегии – все рекомендации специфичны для конкретного контекста,есть очень мало действительно общих стратегий, которым можно следовать во всех ситуациях (возможно эти 6?)
Обратная связь – близкая ( close in) и полная (end-to-end). Обратная связь нужна каждой группе и всей системе; конечному продукту и используемому процессу.
После того, как мы создали декларацию, кто-то сказал мне, что это три и все шесть подходят не только для управления проектами, но и для управления в целом. Ок.
3. Что, если в вашем проекте нет “менеджера проекта”?
Мы все осознавали, что есть много не просто самоорганизующихся команд, но также и самоуправляемых команд, в которых не выделяется “менеджер” или “главный” или любое другое название, которое означает человека на менеджерской позиции.
Применяется ли Декларация к самоуправляемым командам? Я надеюсь на это. Лично я люблю работать в самоуправляемых командах – что-то из серии “я не хочу быть боссом или иметь босса”. Такая команда несомненно подписывается на “групповую ответственность за результат / общую ответственность за эффективность команды”. А также “поток ценности” (не прилагаемых усилий); совместное участие, итерации, предвидение, адаптация, признание отдельных людей (личностей) источником получения ценности, среда, в которой люди могу проявить себя …
Как могут самоуправляемые команды не считать эту декларацию своей? —- То же самое касается добровольческих и благотворительных организаций. Просто работайте над тем, что является потоком ценности для вашей группы, сконцентрируйтесь на этом.
4. К чему ведет эта декларация?
Выпускающий менеджер одной из моих книг попытался управлять процессом создания всей книги. Для всех она сделала расписание с шагом в полдня на четыре месяца вперед. Она сознательно проигнорировала (вот один из примеров ее рвения) письмо, которое я ей послал, и слова всех остальных, когда я был на борту корабля в Карибском море в течение десяти дней, и совершенно не мог проверять рукописи, ведь согласно ее расписанию в эти десять дней в моих руках должны были быть рукописи. Согласно расписанию, я должен был получить рукопись по почте на следующий день, после того, как я уехал в Карибское море, и отправить их назад через день после возвращения. Как только было опубликовано расписание, она стала каждый день звонить менеджеру компании, ответственной за редактуру, чтобы проверить, что все идет в соответствии с ее ежедневным планом. В соответствии с ее расписанием вся трехсотстраничная рукопись должна была быть выслана каждому в полном объеме, так что никакая другая работа не могла быть проведена параллельно, и каждый должен был построить свое личное расписание так, чтобы заниматься только этой рукописью в те дни, которые она им выделила. И конечно она не оставила времени на ревью, потому что конечно редактор не сделает ошибок в редактуре, а я не сделаю ошибок отмечая (соглашаясь!) редакторские правки, а также художник, верстальщик и специалист по индексации.
Конечно, все сразу сошло с рельсов, начиная с моего десятидневного отпуска (заказанного за 4 месяца вперед), и ошибок, сделанных каждым человеком на протяжении работы. Расписание конечно сошло с рельсов и все чувствовали себя несчастными, стараясь работать хорошо и быть профессионалами.
Обратите внимание, сколько пунктов декларации она нарушила. Она отслеживала прилагаемые усилия, а не прирост ценности (т.е. она думала, что отслеживает ценность, конечно, но этого не достаточно), ценность, которую она отслеживала – это было что-то сваленное в кучу, не маленькие кусочки (“постоянная” часть “постоянного потока ценности”), она не привлекла меня, пользователя и заказчика, в свой процесс, она минимизировала взаимодействия (несмотря на мои – как вы можете догадаться – постоянные просьбы о ежедневных или раз в два дня обсуждениях с редактором), не было общей ответственности, не было возможности использовать личные способности, вовлеченные люди были обезличены, не было итераций, времени на адаптацию, никакого предвидения (например, взять хотя бы мое письмо об отпуске), не было приспособления к ситуации.
Что здесь не так? Она не была злой. Если бы ее спросили, я уверен, она была бы полностью согласна с идеей максимизации бизнес ценности, снижения затрат, поддержки качества, и т.д.. Поэтому ее ошибка не в мотивации или намерении. Просто, ее ощущения были неверными.
Я бы хотел, чтобы все люди, вроде нее, подготовленные или нет, думали в терминах декларации. Я бы хотел, чтобы эта дюжина рецептов передавалась с молоком матери, изучалась в детском саду и рефлекторно использовалась всеми, кто отвечает за проект, а использование альтернативных, “традиционных”, обезличенных, пакетно-ориентированных привычек управления проектами было поставлено под вопрос и утверждалось в каждом конкретном случае. Вот к чему, я считаю, должна вести эта декларация.
Поэтому, когда вы прописываете “agile” в своем контракте, включайте также ”используя Декларацию взаимозависимости”. Таким образом, вы получите не только работающее ПО, но также все будет сделано согласно приведенной выше таблице.
5 DOI как 12-шаговый процесс
В Декларации есть 6 утверждений. Это принципы, практики или правила? На самом деле я не знаю (еще), и не уверен, стоит ли мне задумываться над этим (еще). Однако, отбрасывая в сторону правые части предложений, я получил 12 рекомендаций. Поэтому, следуя вслед за лидером Agile Alliance (http://www.agilealliance.org/), я назвал их 12-шаговым процессом (немного сложно звучит, и это моя личная интерпретация DOI; держитесь на дороге). Вот они:
1. Фокусируйтесь на ценности , которая создается и наблюдайте за потоком увеличения ценности.
2. Сделайте маленькой единицу ценности в потоке, в идеальном мире есть единое целое, то, что люди в производстве называют непрерывный поток.
3. Вовлекайте заказчика в постоянное взаимодействие.
4. Стремитесь к общей вовлеченности.
5. Признавайте, что люди как личности, являются непосредственным источником ценности.
6. Создайте среду, в которой они могут проявить себя, изменить что-то к лучшему.
7. Создавайте / проектируйте / работайте инкрементально (сейчас наша промышленность называет эти временные периоды итерациями и я ничего не могу с этим поделат)
8. Предвидьте то, что можете, т.е. используйте имеющуюся у вас информацию!
9. Используйте обратную связь внутри и между уровнями, размышляйте после каждой итерации, и адаптируйтесь к тому, что вы обнаружили.
10. Используйте специфичные для ситуации стратегии (или как вы их называете) и последующие действия.
11. Возложите на группу общую ответственность за результаты (имеется в виду, что нет смысла в том, чтобы обвинять кого-то одного; все отвечают вместе).
12. Помогите каждому почувствовать общую ответственность за эффективность команды.
Перед тем, как я перейду к тому, что эти фразы значат для меня, имеет смысл спросить, “Кто такие ‘Вы’ в том, что касается всех этих вещей?” Я считаю, что это мы все (поскольку я предпочитаю работать в самоуправляемых командах, это сразу становится работой каждого). Однако, в каждой группе власть людей распределяется по-разному. Поэтому я думаю, что каждый человек должен продвигать эти 12 положений, в соответствии с той властью, которая у него есть. Те, у кого больше власти, должен делать больше для их продвижения.
OK, теперь перейдем у моему описанию этих положений. Давайте посмотрим, какой я вижу смысл в этой дюжине предложений.
Фокусируйтесь на создаваемой ценности и отслеживайте поток роста ценности.
Каждый человек или рабочая станция приносит ценность, и есть задействованный поток. В разработке ПО поток часто связан с решениями: кто-то принимает решения по концепции, требованиям, архитектуре / UI / модели данных / тестированию / управлению конфигурациями, и эти решения влияют на других людей. Это я называю “потоком”.
Это странным образом напоминает мне конвейер на фабрике.Правда решение может затрагивать несколько элементов потока одновременно. Наблюдательный человек смотрит, как изменения в одних частях потока влияют на другие части потока, и в соответствии с этим вносит коррективы. Почитайте книгу Elihu Goldratt-а Цель и критическая цепочка (The Goal and Critical Chain) о проектировании потока. Будьте достаточно наблюдательными, чтобы видеть не только усилия.
Вот пример планирования, работы и определения результата по ценности, а не по приложенным усилиям.
Мой бедный сын (которого я продолжаю затаскивать в свои истории) отстал с переводами по немецкому и должен был перевести десять историй за короткое время.
Стратегия, базирующаяся на контроле за усилиями (а также наблюдение за получаемой ценностью (см. следующий пункт)), которую он мог бы использовать в этой ситуации – это прочитать все десять историй, потому что это легко и удобно, он мог бы делать это лежа на кровати и говорить мне, что делает свою работу.
Допустим, он делает это.
Потом прихожу я, злой менеджер, и спрашиваю его, как далеко он продвинулся. Он говорит мне, что сделал 70% , потому что он прочитал все рассказы, и ему только нужно ответить на вопросы.
Конечно, если я достаточно злой, я создам для него диаграмму Ганта (хм, это напоминаем мне того выпускающего редактора…)
Вот какая проблема —- На самом деле он не сделал 70%. Не понятно, на сколько он продвинулся, потому что он еще не отвечал на вопросы. Вполне может отказаться (так действительно оказалось, я должен признать) , что на самом деле он не может ответить ни на один вопрос, потому что он не понял прочитанное.
Он не сделал 70%, он даже не сделал 20% , потому что для ответа на вопросы он должен был посмотреть в словаре кучу слов, начиная уже с первого предложения. Все приложенные им усилия могут послужить только разогревом, что стоит может быть 5%.
(OK, здесь я немного выдумал —- конечно, я не разрешил ему идти этим путем, потому что кое-то в этом я понимаю. Я хочу показать, как бы это сработало если бы я использовал стандартный водопадный метод с диаграммами Ганта и отслеживанием усилий. Его проект пошел бы ко дну, так же как и любой проект в правительстве.)
Итак, какая же альтернатива?
В описанной выше ситуации ценность добавляется только после того, как получены ответы на вопросы. Поэтому я запланировал это и оценивал его в соответствии с отвеченными вопросами.
В этом простом примере “поток ценности” это:
читать
(и смотреть в словарь)
отвечать.
Поэтому, я попросил его прочитать одну историю. Произошла неизбежная катастрофа, и он начал все сначала.
Но заметьте две вещи.
Во-первых, ему пришлось перечитать только одну историю, а не десять.
И когда он сделал это, он увеличил ценность на 10% от общего задания. Он действительно смог сделать это и получить похвалу.
Мы также получили реакцию, смогли адаптироваться, и т.д. и т.д., но это мы еще рассмотрим далее.
Сделайте маленькой единицу ценности в потоке.
В идеальном мире есть единое целое, то,что производители называют непрерывный поток. В мире производства есть понятие непрерывного потока, или единого потока. Заводы, которые делают это, оптимизируют свою работу — я не знаю, какая математика за этим стоит, прочитайте об этом, если нужно. В экстремальном программировании это означает взять одну карточку истории, написать один тест, написать код, который проходит этот тест, отрефакторить этот кусок кода, чтобы добиться хорошего качества кода, и только потом перейти к другому тесту. Я называю это ‘нано-инкремент’. Трудно убедить себя сделать это (ок, для меня, и я видел, что другим тоже трудно привыкнуть к этому). В примере с переводом с немецкого это означает прочитать только одну историю и ответить на вопросы перед тем, как двигаться к следующей истории. По сути, это означает, что нужно прочитать столько,чтобы можно было ответить на один вопрос, перед тем как перейти к следующему вопросу и связанному с ним чтению. На самом деле, это обнаружил не я, а он. Я все еще думал о чтении всей истории и “понимании ее” (сам не знаю почему) перед ответами на вопросы. Однако, мой сын достаточно быстро понял, что для минимизации его усилий достаточно прочитать вопрос, потом прочитать ту часть истории, которая нужна для ответа, и потом повторить все снова. Было ли это хорошо для него? Ок, первые две истории заняли у него четыре дня в среднем, каждая, остальные восемь он сделал за два дня, т.е. в терминах сбережения энергии это принесло свои плоды. Какую пользу это принесло Вселенной?
Лично я не думаю, что она пострадала. Я подозреваю, что из всего этого мой сын понял, как “обманывать легально” (прочитайте мои посты про Agile разработку, чтобы понять это) , чем то, что если бы он тщательно смотрел каждое слово, то не понял бы историю. В любом случае, сейчас он нагнал немецкий. Как ни странно, здесь можно провести параллель с разработкой ПО, это то что называется “разработка через тестирование” (“test-driven development”). Сначала напишите тесты, затем напишите такой код, который их проходит. Как написал один разработчик, “это обман!” Понимаете о чем я говорю, насчет обмана на законных основаниях? И как поживает Общее благо Вселенной? Конечно я применил это при строительстве фундамента под нашим домом (я знаю, знаю, большинство людей строят сначала фундамент, а потом ставят сверху дом. Не загружайте меня деталями). Во всяком случае, сначала мы построили четверть дома, чтобы узнать о грязи под ним, бревнах (много удивительных сюрпризов), и использовании фанеры вместо бетона. Я не нашел нано-инкременты, но мы сделали единицу ценности настолько малой, насколько смогли (см. ниже итерации и адаптацию).
Вовлекайте заказчиков в частые взаимодействия.
Кто заказчик? Я немного отклонюсь от вопроса, если не возражаете. ‘Заказчик’ это не простое слово,и оно мне не очень нравится. ‘Пользователь’, ‘клиент’, ‘спонсор’, ‘покупатель’ – оно может означать все это. В случае с моей рукописью, редактор должен был удовлетворить некоторые из моих эстетических прихотей, т.е. в этом случае я был ‘заказчиком’. Я обдумывал это раньше, и знаю, что если бы мы работали вместе после того, как была сделана первая глава (итерация / адаптация) и привыкли бы к стилю друг друга, мы бы смогли избежать множества острых замечаний, которыми мы обменивались с ним по почте. В самом деле, если бы мы могли связываться друг с другом каждые два дня (в идеале – каждый день , но это конечно несбыточная мечта), то смогли бы создать основанные на здравом смысле договоренности и допущения, что значительно бы ускорило работу редактора (обратите внимание на “непрерывный поток”).
Наша команда по закладке фундамента часто с нами связывалась; agile разработчики любят, чтобы заказчик / пользователь /спонсор приходил и оценивал растущую систему еженедельно, или ежедневно, и т.д. Такая тактика сокращает блоки, движущиеся по цепочке ценности, повышает скорость получения отклика, уменьшает объем переделок, и (если все в порядке) воодушевляет заказчика по мере продвижения вперед. В то же время, у заказчика появляется шанс удостовериться в том, что он получит то, что ему нужно / что он хочет (пусть другие ссорятся по поводу разницы между этими понятиями).
Стремитесь к общей вовлеченности.
Это немного сложнее. Допустим, выделаете новую камеру или обувь для массового рынка, что означает “вовлеченность” для заказчика? Честно говоря, я не знаю. Чувствовали ли мы с сыном “общую вовлеченность”, когда работали над его заданием по немецкому? Нет, я порой делаю эту ошибку, но на самом деле не стоит слишком эмоционально относиться к домашним заданиям своих детей. С другой стороны, строители нашего фундамента были убеждены, что мы вовлечены в работу, проектирование и то, что они делают для нас. Понятно.что это подходит, когда есть один заказчик или небольшая группа заказчиков (например, возьмем ситуацию родитель – учитель в вашей школе, все внутренние IT магазины, и т.д. ). В идеальной ситуации есть только “мы”, и “мы” собираемся что-то сделать, построить, что бы это ни было. И когда заказчик / пользователь / спонсор переходит с противоположной стороны стола на одну сторону с разработчиками, начинают происходить прекрасные вещи, например улучшение обратной связи, вовлеченность и удовлетворенность. (А также будет больше помех и отвлечения внимания, будьте готовы к этому —- никто не говорит, что все это бесплатно, не так ли?)
Признавайте, что люди как личности, являются непосредственным источником ценности.
Первые два пункта из перечисленных выше идут в одном ключе с принципами Lean производства и дизайна. Но книги на эти темы считают людей фишками,которые можно передвигать туда-сюда. Математика – это прекрасно, но страдает ощущение личности. Есть только “мы”, и мы не роли, должности, штат или численный состав, мы реальные люди, не “народ” в своей массе, а группа отдельных личностей, со всем,что это с собой несет. И именно мы, отдельные личности, поставляем ценность. Особенно это касается таких творческих активностей, как управление бизнесом и разработка / проектирование товаров и систем. И везде. (Кое-кто может может сказать, что кошки и собаки, и даже рыбы тоже приносят ценность, как личности. Я не уверен насчет муравьев.) Некоторые люди действительно полагают, что разработка ПО это конторская работа. Я не знаю,откуда у них появилась эта идея. Разработка ПО состоит только из изобретения и взаимодействия, двух отличительных черт человеческой личности. То же самое касается управления бизнесом. А также перевода с немецкого. Редактирования текстов. Разработки новой конференции. Даже строительство фундамента: я полагался на мудрость и опыт всех, кто участвовал, чтобы помочь справиться с удивительным множеством неожиданных ситуаций, которые возникли на нашем пути.
Дело в том, что если вы забываете о людях (как личностях), которые приносят ценность, то вы забудете сделать поправку на их слабости, и забудете воспользоваться их индивидуальными сильными сторонами (сейчас я думаю о тренере Chicago Bulls , который смог сплотить их как команду, обратив внимание на уникальность каждого, а также о многих подобных примерах). Сделано достаточно, чтобы можно было с уверенностью сказать, люди, которые чувствуют себя вовлеченными и оцененными, работают лучше. Прочитайте First Break All the Rules , если вы еще не убеждены.
Создайте окружение, в котором люди могут проявить себя, изменить что-то к лучшему.
Этот пункт тесно связан с предыдущим. Одна из ключевых внутренних мотиваций, это желание людей изменить мир. Nancy Garbett (спросите ее, что значит “Corporate Shaman”) задала такой вопрос: “Что является продуктом вашего продукта?” Другими словами, как вы изменили мир? (например, моя работа – помогать людям более эффективно проявлять себя, менять мир. Я получаю удовольствие, когда вижу , что другие рады тому,что их вклад в создание чего-либо увеличивается. Рост общего удовлетворения доставляет удовольствие мне.) Если окружение таково, что люди не видят возможности что-то изменить к лучшему, то чувствуют потерю контроля, полномочий, гражданских прав. Они сокращают свои попытки сделать что-то и свое внимание к этому. Как только снижаются эффективность и результативность, общие результаты снижаются соответственно.
Давайте возвратимся к рукописи моей книги. Насколько хорошо работали редактор и художник, когда были обезличены и лишены полномочий? Как стали бы выглядеть картинки и указатель в книге? (К счастью мы смогли изменить тот процесс, который использовался при создании книги! Начальник редактора и я взяли на себя процесс, разделили книгу на главы, и настроили работу по каждой главе отдельно (вот какой была единица потока), повысили взаимодействие и т.д.. Это называется самоорганизацией или восстанием или плохим словом, в зависимости от вашего взгляда. Однако, это сработало, и у нас получился проект, который уже выходил из под контроля (ок, в этой истории больше переплетений, не буду на них сейчас останавливаться.)) В том случае.если вы работаете в некоммерческой организации, “изменить к лучшему” – это то, что вы можете предложить. Удивительно, как много это значит в строго коммерческих организациях.
Стройте / проектируйте / работайте инкрементально
(наша индустрия называет эти временные периоды итерациями и я ничего не могу с эти поделать)
Итерация означает часть общего доступного времени, чтобы группа могла проделать полный цикл работ, и посмотреть на это. Если цикл короткий, я называю это_процесс_в_миниатюре_ ( _process miniature_) —- ценность миниатюрного процесса в том, что каждый может посмотреть на весь процесс в целом, и посмотреть, как разные части процесса соединяются между собой. В зависимости от обстоятельств вы можете создать или не создать реальную часть чего-то, что можно поставить. Инкрементально – означает проектирование / построение / выполнение одного кусочка чего-то общего, что нужно создать. Затем нужно собрать, интегрировать все части, после того, как они сделаны. Например, полностью закончить четверть фундамента; одну историю по немецкому, вместе с вопросами, одну user story в XP.
Удивительно, но почти все можно сделать инкрементально. Обратите внимание, что я говорю почти. Я не могу придумать, как разработать и запустить конференцию инкрементально – я не могу придумать другого “водопадного, супер объединяющего” проекта, чем конференция (как вы можете догадаться, для меня было очень тяжело обойтись без инкрементов и итераций на конференции). Но в основном все вещи можно сделать инкрементально. Фундаменты, проектирование и строительство подводных лодок, самолетов, домашних заданий, гражданских и инженерных проектов, реклама и маркетинг … Просто подумайте, и вы найдете способ. Почему полезно работать инкрементально? Обратная связь и боевой дух. Когда закончен один кусок, вы получаете отзывы о команде, процессе и продукте. Спонсоры и заказчики получают видимые результаты, что их вдохновляет. Команда видит объем сделанного, что ее вдохновляет. И так далее. Инкрементальная разработка – одна из нескольких практик, которые я стараюсь применить в любой ситуации, настолько она мощная. Я еще раз остановлюсь на этом в пункте “обратная связь и адаптация” .
Предвидьте то, что можете, т.е. пользуйтесь информацией, которая у вас есть
Когда мы писали Agile Manifesto, я не ожидал, что некоторые сочтут неудачным использование имеющейся уже информации. Меня удивило,что люди начали спорить о том, что если кто-то достаточно гибок (agile), то все обстоятельства могут быть преодолены за счет достаточной гибкости (agility). Для обложки своей книги Agile Software Development я выбрал картинку с бенгальским тигром, как пример настоящей гибкости (agility). Однако даже бенгальский тигр наблюдает за каждым шагом своей добычи, стараясь предвидеть куда она пойдет, а не просто бежит за ней. (С другой стороны, конечно, гибкая и быстрая жертва также занята тем, что наблюдает за тигром, за тем, куда он идет). Для эффективного управления ответственному лицу или команде (в зависимости от структуры власти) стоит пользоваться доступной информацией.
У каждого человека есть то, что я называю “мыслительный горизонт”, период времени, в течение которого они могут продуктивно думать о будущем, не повторяя себя. Для меня, в шахматах, это несколько меньше, чем один ход :-(; в разработке ПО – это что-то около трех дней; в некоторых обстоятельствах у меня получилось увеличить это до трех недель. В какой-то момент новые мысли ускользают, и и я начинаю прокручивать свои мысли. В этот момент лучше остановиться и начать делать что-то,чтобы получить отклики. Но в это время у меня появляются разные интересные наблюдения , которые я имею в виду пока наблюдаю, как разворачивается будущее. Как добыча бенгальского тигра, если у меня получается успешно узнать,откуда ждать беды, я могу выбрать.начать ли мне двигаться заранее или подождать, пока он подойдет поближе, и у меня будет больше информации. Это часть выбора стратегии (см. ниже).
Например: при создании конференции мы внимательно отслеживали объемы зарегистрировавшихся на раннем этапе. Были контракты, которые нельзя было отозвать в течение последних 30 дней, поэтому мы должны были заранее оценить число посетителей. Затем, в течение 30-дневного периода, мы разработали три чрезвычайных плана: полномасштабное сокращение, удаление из конференции всего, что можно было убрать (лучше потерять деньги, чем опустить качество ниже определенного уровня); средний вариант и полное соответствие первоначальному плану, в случае, если у нас будет много регистраций в последний момент.
Комбинируя предвидение. взаимодействие и обратную связь, мы смогли настроить планы, так чтобы быть уверенными, что у нас есть баланс между числом посетителей и содержанием конференции. Еще один пример: история с публикацией книги, надо было просто посмотреть расписание отпусков, мое и других. В ситуации с домашним заданием, нужно было посмотреть, какие еще активности запланированы на ключевые вечера и дни. В разработке ПО и в инженерии есть фактор нагрузки. В строительстве фундамента, нам нужно было обратить внимание на погоду —- некоторые работы нужно было сделать до снега. И так далее. То, что вы достаточно гибки (agile) не означает, что вы должны быть глупы и не думать о будущем.
Пользуйтесь обратной связью внутри и между уровнями, проводите анализ после каждой итерации, и адаптируйтесь к тому, что вы обнаружили.
DOI говорит “адаптироваться”, но здесь есть некоторые допущения. Специфичные для ситуации стратегии рассматриваются отдельно, поэтому я хочу сфокусироваться на адаптации после итераций. Чтобы адаптироваться, вам нужна обратная связь и размышления (не стоит собирать отклики,если вы не собираетесь обдумывать их!). Близкий отклик означает,что каждый человек высказывает свое мнение о том, что они делают. Полная (end-to-end) обратная связь (или еще говорят межуровневая ) означает, что вы получите мнение о том, как работает множество человек, желательно взаимосвязанных. Пример близкого отклика – это unit тест для части программы. Сам тест маленький, тестируемый код маленький, тест обычно делается в интересах программиста. Тест говорит ему / ей, какие изменения привели к нарушениям, так что программист может вернуться и исправить ошибку. Пример полной обратной связи – это число звонков, полученных call – центром . Это отражает (один из аспектов) общее качество продукта. Не имеет значение, была ли ошибка в требованиях, дизайне пользовательского интерфейса, кодировании или тестировании, или в документации, сам факт, что кто-то позвонил, говорит о проблеме.
Используйте специфичные для ситуации стратегии (или как вы их называете) и последующие действия.
Возложите на группу общую ответственность за результаты (имеется в виду, что нет смысла в том, чтобы обвинять кого-то одного; все отвечают вместе).
Помогите каждому почувствовать общую ответственность за эффективность команды.
(Да, к последним трем пунктам я должен добавить больше текста См. также The DOI explained href=”http://www.stickyminds.com/BetterSoftware/magazine.asp?fn=cifea&id=77.)” target=”blank”>http://www.stickyminds.com/BetterSoftware/magazine.asp?fn=cifea&id=77.)
