Отрывки из второй книги

Друзья, как и обещали, предлагаю вашему вниманию отрывки из нашей второй книги с рабочим названием "Мастер управления ИТ-проектами и проектной средой": 

Как читать книгу?

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

Эта задача была непростой и в первой книге, несмотря на то, что уровни квалификации в ней выстроены как этапы карьерного развития. Непросто потому, что крайне сложно «однозначно» соотнести знания, навыки и умения с каким-то конкретным «квалификационным уровнем» при этом не перегружая «требования» к квалификации. Должен ли младший аналитик знать вот эту теорию? А должен ли он уметь делать вот это? Или он это должен уметь все-таки на следующем уровне своего развития, уже как старший аналитик? Такие вопросы мы задавали 100 раз сами себе, когда писали первую книгу. В итоге мы нашли некоторые границы квалификаций, которые более-менее отражают взгляд авторов на этапы профессионального и карьерного развития аналитиков. 

Впрочем, мы никогда не скрывали, что, даже не смотря на то, что эти «требования» реальными требованиями не являются и часто они избыточны – подходите с головой и выбирайте только то, что вам реально нужно в работе – о чем нам впоследствии и писали многие наши читатели. 

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

Мы также достаточно долго думали как упорядочить паттерны и в конечном итоге решили упорядочить паттерны по субъектам управления. Таким образом, все паттерны в книге сгруппированы по какому-то единому целевому признаку и отсортированы внутри группы в «рекомендованном» порядке их применения. 

Благодаря этому, мы надеемся что, начинающие управленцы смогут увидеть место каждого паттерна в, скажем так, "возможной цепочке их применения", а также смогут понять каких знаний и опыта им не хватает для того, чтобы применять паттерны в "правильном" (то есть рекомендуемом авторами) порядке. 

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

А для ориентации в материалах книги и паттернах в привязке к квалификации, в разделе «Сводная таблица паттернов» мы приводим таблицу всех паттернов, которые есть в этой книге, в зависимости от квалификации / профиля менеджера. Но эта зависимость, как вы уже понимаете, не является строгой, единственно правильной и тем более не может рассматриваться как какие-то квалификационные требования.

[...]

Что такое «паттерн»? 

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

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

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

Паттерны особенно хороши для организаций с конфигурацией «профессиональная бюрократия» (смотри раздел «Конфигурации организации» первой книги серии «Путь аналитика»), к которой относится разработка ПО, так как относятся к стандартизации знаний и квалификации, - одним из наиболее эффективных методов деятельности в организациях подобной конфигурации. 

Для максимального точного и однозначного понимания смысла паттерна приведем пример паттерна «глажка мужской рубашки». 

Сначала прогладьте воротник, (воротник всегда гладьте изнутри), затем прогладьте рукава рубашки, потом прогладьте плечи и верхнюю часть, расположив рубашку на полукруглой части гладильной доски (лучше, если вы освежите рубашку водой из пульверизатора), затем, начиная с одной стороны рубашки и постепенно перемещая к себе не проглаженные участки на горизонтальной части гладильной доски, прогладьте всю рубашку целиком. Если вы спешите – тщательно проглаживайте только верхнюю часть спины и края рубашки с пуговицами и петельками. 

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

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

Паттерн не является ни жесткой методологией, ни описанием ЖЦ, ни четким алгоритмом. Паттерн это воспроизводимый поведенческо-организационный шаблон, направленный на достижение определенного результата.

В начале каждой главы с группой паттернов мы будем приводить вот такую табличку, чтобы вам было проще ориентироваться:

Название паттерна; Параметры среды ; Кому это надо? ; Зачем это надо? ; Организационный аспект ; Поведенческий аспект

Паттерн «погладь рубашку»;
• Организация любого масштаба • Уровень формализации процессов – любой • Уровень квалификационных стандартов – любой; 
• Любому кто гладит мужские рубашки;
• Узнать еще один способ глажки;
• Порядок глажки • Применение гладильной доски в процессе глажки;
• Хорошие практики и рекомендации • Само-настрой • Включенность в действительность;

[...]

Паттерн «удаленное управление»

В современных компаниях очень часто работает распределенная команда. Развиты такие формы трудовых отношений как аутсорсинг, аутстаффинг, удаленная команда, распределенная комадна. 

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

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

Я сторонник позиции, что распределенная команда может работать так же хорошо, как и команда «под крылом». Я считаю, что очные встречи исключительно полезны только в трех случаях: познакомиться (и конечно, kick-off meeting) , мозговой штурм, ну и … отпразновать успешное окончание проекта. 

Как же добиться эффективной работы распределенной команды? 
Мой рецепт:
1. Паттерны «WAS» 
2. Паттерн «смартинг»
3. Паттерн «чеклистинг»
4. Специфика виртуальных встреч
        a. Любая встреча с сотрудниками проводится на 2 ноутбуках – чтобы видели меня самого на первом ноутбуке и видели то, что я «рисую» на втором ноутбуке 
        b. Придется более активно «рисовать» свои идеи – вместо флипчарта и доски можно вполне использовать обычный Pain. Да, это потребует некоторой сноровки работы с мышью, но это вопрос 2х встреч. 
        c. Видеоконференция - в идеале желательно видеть видео всех участников и иметь возможность передать «флипчарт» любому из участников совещания
        d. Протокол пишется всегда ! 
        e. Протокол пишется всегда той стороной, которой:
               i. Ставили задачу 
               ii. Где больше удаленных сотрудников
        f. Протокол пишется всегда ! Даже если это 4 строки.
        g. Протокол пишется максимально коротко но информативно
        h. Протокол рассылается в течении 2х часов после совещания 
        i. Все обязаны поправить протокол или явно ответить «ок».
5. Адаптированные базовые правила
       a. Тим лидеры доступны по почте всегда. Отвечают в течении часа. 
       b. Любой член команды доступен по скайпу в рабочее время
       c. 3 итерации дискуссий ведется в переписке, после чего дискуссии продолжается по скайпу
       d. В случае не работы почты и скайпа любой член команды доступен по мобильному телефону
       e. Ответственность за качество и правильность понимания переданной информации и на принимающей стороне («я правильно понял, что …», «под этим и этим имеется в виду то то и то то…» и т.п.) и на передающей стороне («подтвердите что принцип передачи данных понятен», «ответьте какие шаги вы собираетесь предпринять для снятия рисков…») 

Естественно что необходимым условием для того, чтобы этот паттерн работал является открытость и коммуникабельность участников команды. Также этот паттерн лучше работает, если команда организована «кустом», то есть у вас есть группы удаленных сотрудников и руководители этих групп. 

Почему этот паттерн я поместил в раздел паттерны управления функциональным отделом? Главным образом потому, что если компания работает с аутсорсинговыми командами на постоянной основе, то вы с большой вероятностью и будете руководителем удаленной группы в формате «куста» для менеджера проекта или руководителя разработки ПО. Ну а во вторых, потому что если даже ваш отдел «виртуальный» и не все ваши сотрудники находятся физически рядом с вами, вы все равно должны строить единый фундамент отдела. 

Ну а чтобы это было возможным и нужен этот паттерн.
(c) 

Друзья, мне и моим соавторам будет интересно ваше мнение: 
1. Насколько удобно воспринимать информацию, поданную как паттерн? 
2. О каких субьектах управления или о паттернах в каких областях касающихся разработки ПО вам было бы интересно прочитать в этой книге? 
3. Присылайте проблемные случаи и вопросы связанные с управлением разработкой ПО (проектами, продуктами, отделами), мы с коллегами постараемся ответить вам и возможно также включим в книгу эти ответы.

Пишите на почту This e-mail address is being protected from spambots. You need JavaScript enabled to view it.

Спасибо.

С уважением,
Перерва А.Д.

Дополнительная информация