Спойлер про лучший домик для поросенка. На мой взгляд, вопрос “какие методы и инструменты лучше всего подходят для проектов внедрения?” вообще неуместен. Так же как вопрос, какой дом будет являться идеальным. Не бывает дома подходящего для любых условий. И в базовом курсе по управлению ИТ-проектами, который я буду вести на Инфостарте, не будет рассказа про идеальный метод. Мы вместе будем анализировать успешный опыт предшественников, размышлять, какой дом лучше построить в ваших обстоятельствах.
Шаг 1. Сначала думаем, потом прыгаем
Не бывает универсальных методов. Лучше день потерять, потом за 5 минут долететь. Поэтому когда мы видим проект, который нам предстоит, полезно замедлиться и подумать о том, как именно стоит его реализовывать.
По каким критериям мы на практике выбираем, как будем вести тот или иной проект?
- Что мы умеем - это на самом деле логично
- Что написано в умных книжках - Герман Греф, скажем, регулярно новую книжку читает, и Сбербанк лихорадит после этого
- Что рекомендует 1С - в частности, описанные в ПрофКейсе технологии
- Что делают окружающие - все побежали, и я побежал, вот соседи Agile внедрили, и у них закрутилось
- Что выглядит по-умному - искусство сказать, что
король-то голыйбизнес-гуру предлагает неработающую модель - очень непростое - Что в прошлый раз позволило добиться успеха (кстати сказать, здесь кроется одна из распространенных ловушек руководителя - успешные руководители часто перестают быть гибкими)
По каким критериям это стоит делать в действительности?
- Возможности частых поставок
- Сложность проекта
- Понимание средств технической реализации
- Степень определенности требований
- Готовность Заказчика включаться в работы в процессе проекта
- Компетентность команды/компетентность руководителя
- Наличие базового доверия.
- Готовность работать в парадигме Win/Win
Немного про подходы я рассказывала в своей статье Можно ли объять необъятное, или Чем Agile отличается от водопада? Но дьявол, как известно, в деталях. И подробнее про то, какие подходы бывают, как выбрать нужный, мы поговорим на первом вебинаре курса. В качестве бонуса будет рекомендуемый чеклист по выбору метода для управления проектом.
Что делать, если видите, что никакой метод не подходит для реализации проекта? Не проходит ни по каким критериям? Мы не можем ни полноценно использовать “Водопад”, ни “Agile”? Скажем, заказчик не может сформулировать требования, но не готов приступать к работе без утвержденного ТЗ. Не знает объем работ, но не готов к скользящему бюджету и т. п. Если довести эту ситуацию до логического завершения, то можно только вспомнить один из моих любимых анекдотов…
Лебедь и маленькая серая уточка (Драма, осень, озеро)
Озеро. Лебеди разминают крылья.
Красавец-лебедь картинно становится в позы культуриста, растягивая каждое сухожилие, поигрывая мускулами.
Подходит маленькая серая уточка, мнется, начинает (жалобным, слегка писклявым, дрожащим голосом):
- Коне-е-е-е-е-ечно… Наверное, на Юг полетите?..
Лебедь, басом, красиво выгибая спину:
- Ну, да, на Юг. Ага. Там тепло, да.Уточка:
- Коне-е-е-е-е-ечно… А я ту-у-у-ут останусь… Замерза-а-а-а-ать…
Лебедь:
- Полетели с нами, да. На Юг. Ага. (тянет мускулистую ногу)
Уточка:
- Коне-е-е-е-е-ечно… У вас крылья во-о-о-о-о-он какие… А у меня ма-а-а-а-аленькие, я упаду, разобьюсь и умру-у-у-у-у…
Лебедь:
- Так мы тебя, того. Поддержим, да. Воздушные потоки, понимаешь.
Уточка:
- Коне-е-е-е-е-ечно… А в дороге я проголодаюсь, обессилею, и умру-у-у-у-у…
Лебедь:
- Ну, так будем ловить жуков. Да. Сочных жуков.
Уточка:
- Коне-е-е-е-е-ечно… Жуки большие, у вас клю-ю-ю-ю-ювы вон, какие, а у меня ма-а-а-а-аленький, я не смогу проглотить, подавлю-ю-ю-юсь…
Лебедь (похрустывая, разминает крылья):
- Так мы тебе их того. Разжуем, да. Будешь есть, нормально же.
Уточка:
- Коне-е-е-е-е-ечно…
Лебедь (выпрямившись, глядя на уточку):
- Так. Нах$%.
В том смысле, что если у вас вводные явно показывают, что у вас ничего не получится, то скорее всего, у вас ничего не получится, и лучше за такой заказ не браться. Умейте быть лебедем и вовремя давать достойный ответ. С уважением отношусь к людям, умеющим при необходимости на заявление "Ты сильный, ты справишься!" отвечать "Я умный, я даже не возьмусь". Здесь можно возразить, что иногда нам деваться некуда, и приходится соглашаться на заведомо проигрышные условия. Ну что ж, это тоже наш выбор. За всякое принятое решение нужно платить. Когда мы делаем выбор, мы принимаем плату, которую придется заплатить за это решение, и принимаем риск, сопряженный с этим решением. Тут деваться некуда.
Шаг 2. Учимся строить каменный домик для Наф-Нафа
В своей статье я нарушу хронику английской сказки и начну с каменного домика (если честно, я даже специально погуглила, чтобы уточнить, как какого поросенка звали по версии Сергея Михалкова - ну не могу этого запомнить, каюсь, слишком уж все эти имена похожие).
Почему начнем со сложного и основательного? Как никак, то, что называется “классические методы управления проектами” - это некая основа основ, общепринятая база, от которой давно отталкиваются. И в моей практике строительство соломенного домика Ниф-Нифа применение Agile-практик оказывается успешным чаще всего не тогда, когда оно идет от кувыркания в зелёной траве и купания в лужах от управления проектами как попало по принципу “нам лень готовить проектную документацию, поэтому мы будем работать по Agile”. А когда Наф-Наф уже умеет строить каменный домик мы уже умеем работать с проектами основательно, то можем осознанно упростить процедуры, сосредоточившись на главном. То есть те, кто знакомы с "негибкими подходами" проектного управления, имеют больше шансов освоить "гибкие".
С применением PMBOK в проектах внедрения (да и не только) есть большая засада. Как вы думаете, что проще - взять красивые шаблоны и сделать вид, что вы их прикрутили к проекту, заполнив их как бог на душу положит, или вникнуть в суть и понять, в чем они могут пригодиться: кастомизировать, убрать лишнее и т. п.? Конечно же, в разы проще создать видимость использования метода, чем использовать на самом деле!.. Особенно, когда руководство/заказчики/сертифицирующие органы (включая компанию 1С, требующую от франчайзи применения методологии для получения статуса) и т. п. этого требуют. Поскольку люди всегда стремятся упрощать свою работу, то заметная часть применения шаблонов классического управления, с которой я сталкивалась, используется, увы, исключительно для галочки. И именно отсюда различные истории, когда от неумного применения методологии больше вреда чем пользы. У меня вполне себе есть грустные байки на эту тему, да подозреваю, что у многих читающих этот материал тоже (поделитесь - любопытно?..)
То есть, упрощенно говоря, управление проектами можно представить в виде вот такой диаграммы Венна.
И самое вкусное, конечно же, спрятано в центре. На пересечении двух кругов. Но докопаться дотуда не просто. Скажу больше, не все гуру и ведущие тренингов всерьез докопались - многие остались на левой половине. Если ограничиваться чтением умных книжек и скачиванием шаблонов, то, увы, попасть туда не получится. А как туда попасть - мы будем разбирать на втором и третьем вебинарах учебного курса, где будем прикручивать эти самые шаблоны к реальности слушателей, безжалостно отрезая ненужное. А на третьем обсудим, как работать с командой проекта, потому что, как известно, одно дело - придумать теорию, а другое - обеспечить
Шаг 3. Учимся строить соломенный домик для Ниф-Нифа
Как уже писала выше, в реальности каменный домик не всегда является оптимальным решением. Скажем, в Японии, волков, судя по всему, было мало, а землетрясения наоборот были часто. И японцы осознанно старались строить не основательные каменные постройки, а дома с легким каркасом, которые при подземных толчках просто складывались, минимизируя человеческие жертвы.
Вот и с управлением проектами - очень часто нам нужны простые и удобные инструменты, позволяющие реагировать на быстро изменяющуюся действительность.
В этом месте, если проект внедрения поручен ИТ-подразделению внутри компании (или дочерней компании), она оказывается в более выигрышном положении - ибо строить взаимоотношения Исполнитель-Заказчик по гибким методам во внутренних проектах проще, чем во внешних. Но во внешних тоже возможно - практика показывает. Главное - не увлекаться, а то будет как в левой части картинки. Тут про продажи, но с проектным управлением похоже. Картинка взята с просторов Интернета, кто автор - не удалось найти к сожалению. Если знаете - поделитесь… Кто найдет ошибку в подписи - тому лайк.
Про Канбан-систему я уже писала две статьи: Канбан в условиях российской действительности и Что немцу хорошо, то русскому... как минимум небезынтересно
Про Скрам как бизнес-процесс постараюсь написать в ближайшее время. А вообще, подробно раскладывать по полочкам разные виды “соломы” для домиков собираюсь на четвертом и двух последующих вебинарах курса.
Шаг 4. Поросята идут лесом, а мы строим домик для себя
В профиле моего аккаунта в livejournal в свое время стояло эпиграфом высказывание Козьмы Пруткова: “Не нужно плыть по течению. Не нужно плыть против течения. Нужно плыть туда, куда тебе надо”.
Вот на 4-ом шаге мы учимся строить такой домик, какой нам нужен. То есть разбираемся, как продуктивно скрестить ужа и ежа, чтобы ваш проект “взлетел”.
Здесь может возникнуть резонный вопрос - позвольте, а зачем вообще нужны второй и третий шаги??? Зачем рассматривать ортодоксальные подходы вместо того, чтобы сразу запускать гибридные методы?.. Ответ прост - для принятия взвешенных управленческих решений нам сначала нужно познакомиться с инструментами. Иначе получается как в истории про сову (см. комикс)...
Немножко на эту тему я рассказывала в докладе на Infostart Event 2018 Education, ну а конкретика про гибридные методологии будет в седьмом вебинаре курса.
Шаг 0. Кажется, мы забыли подготовить площадку для строительства...
На самом деле, определяющее значение для успеха проектов имеет так называемое окружение. Нам важно понять уровень зрелости компании, как выстроены бизнес-процессы. Проекты нам потом предстоит передавать на сопровождение (увы, очень много историй, когда внедрение вроде как состоялось, но потом пользователи возвращаются к выполнению рабочих задач привычными методами).
На первый взгляд может показаться странным, почему про выстраивание бизнес-процессов в целом в организации я говорю не в начале, а в конце.
И в статье, и в учебном курсе (восьмой вебинар).
На то есть несколько причин.
Во-первых, чисто статистически, для большей части читателей (/слушателей онлайн-курса) вопросы выстраивания бизнес-процессов лежат вне зоны их ответственности. Мы все-таки ориентируемся на руководителей проектов, в крайнем случае на будущих руководителей проектов. И насущные вопросы более актуальны, чем общие.
Во-вторых, слона лучше есть по кусочкам. И преобразовывать компанию целиком - это отдельная история. И важно для начала как минимум.
А вообще, организация ИТ в компании, включая сопровождение продуктов 1С, выстраивание ITSM (ИТ как услуги) - это отдельная тема, как для серии статей, так для учебного курса. О ней я поговорю немного позже…
Коллеги, следите за новыми публикациями на тему проектного управления.
Подробнее об управлении ИТ-проектами вы можете узнать на моих онлайн-курсах
