3 ноября 2011 в 20:06

Сергей Архипенков — Теория и практика адаптивного управления проектом tutorial

Архипенков Сергей — эксперт в управлении разработкой ПО, более 30 лет в разработке ПО, PMP® PMI, вице-президент Гильдии менеджеров программных проектов. Активный «продвигатор» и «задвигатор» теории и практики управления проектами и людьми в проектах по разработке ПО. Активный заседатель программных комитетов. Из последнего — председатель программного комитета конференции «Software Project Managment Conference» (ноябрь, Санкт-Петербург).

Ниже опубликован доклад Сергея с конференции CodeFest, на тему «Теория и практика адаптивного управления проектом».



Видео доклада:
.

Аудио доклада
polazhenko.podfm.ru/my/14/download/arhipenkov.mp3

Слайды:
www.slideshare.net/codefest/s-arkhipenkov-codefest

Текст доклада:
Спасибо, Артём, спасибо всем организаторам, которые пригласили меня выступить перед такой представительной аудиторией.
Доброе утро, уважаемые коллеги, точнее сказать – не коллеги, а братья по разуму. Потому что программист — это не профессия… Кто сказал диагноз? (смех в зале) – Нет, не диагноз, программист – это образ мышления и особый склад ума.

Задачка: Баратино дали 5 яблок, три из них он отдал Мальвине. А, теперь каверзный вопрос – сколько яблок осталось у Буратино?
Только программисты знают правильный ответ (варианты из зала 5, 10). Ну, менеджеры собрались в зале – понимаю.
А правильный ответ, — очень простой — не известно! Почему? А потому что в начальных условиях не сказано о том, обнулили ли вначале ячейку с адресом Буратино, перед тем как туда добавили 5 яблок.

Ну вот тут уже сказали, что я разрабатываю программное обеспечение 35 лет. Ну, последние годы, естественно, — меньше разрабатываю, больше руковожу. И вот я сейчас попытаюсь за полчаса рассказать всё самое главное, что мне удалось накопить за эти годы.
Нет одного ЛУЧШЕГО способа решать дифференциальные уравнения. Алистерн Кобберн – зачинатель Agile движения — он исследовал сотни проектов за последние 20 лет и сделал вывод, что нет никакой корреляции между процессами, по которым идут проекты и результатом — успешный или неуспешный проект. Я буду утверждать, что есть такой процесс и называется он – адаптивное управление.
Мы будем говорить сегодня о принципах, потому что знание небольшого числа принципов, как говорил Гельвеций, освобождает от необходимости запоминания множества фактов. Существенных принципов будет семь, они самые главные. Но прежде, чем перейти к ним – я расскажу, что такое адаптивное управление.
Из 35 лет, в течении которых я разрабатываю программное обеспечение, 20 лет я разрабоатывал ПО в Центре управления полётами. Вот имел такое счастье, имел такой опыт. И очень хорош знаю, как работают системы управления нашими ракетами. И вот не поверите, аналогия один в один, если сравнить историю развития систем управления баллистическими ракетами и историю развития подходов к управлению програмными проектами. Первый способ управления ракетами – баллистический полет.



Ну, значит более 1000 лет назад, вспоминаем историю, в Китае был изобретён порох и существовали баллестические ракеты и вот одно из сказаний из «Повести временных лет», если не ошибаюсь (с историей хуже знаком, чем с программированием) о том, как княгиня Ольга осаждала город древлян, и потом согласно легенде она собрала по голубю и по воробью с каждого двора и, привязав паклю, зажгла город. Есть мнение, ну версия, так-сказать. Истории нет – есть версии разных людей о том, как это могло бы быть. Одна из версий в эссе «Память» Чевелихина состоит в том, то что Ольга сидела и полгода ждала, пока ей из Китая привезут эти ракеты. Их привезли и она ракетами этот город зажгла. Ну значит, тогда вот ракеты и программы летали одинаково – «как получится». Выставляли некий начальный угол, который как считали наводил на цель… Да, можно так летать, но не очень далеко и не очень точно. Так это продолжалось до середины 50-х годов прошлого века. Когда сложность задач повысилась на 4 порядка — раньше летали на один километр и это было супер достижение, а теперь надо на 10 000 киломметров летать и не промахнуться по стране желательно. Стали внедрятся системы управления. Первые системы управления были на основе аналоговых вычислителей, когда из сопротивлений, индуктивностей и ёмкостей набиралась схемка, которая моделировала полёт по заданной траектории. На борту стояла инерциальная система измерения скорости и местоположения в пространстве. Каждый раз, когда отклонения достигали недопустимых пределов, система управления возвращала ракету на попадающую траекторию. Аналог в нашей отрасли программостроения всему этому – это «водопад». Все слышали замечательный музыкальный ролик Максима Дорофеева “Raise and fall of waterfall” про то, как был изобретён водопад отцом Уокера Ройса. Хотя он изобрёл совсем другое. Поищите, в интернете есть.
Значит идея очень простая – есть регулятор, есть отклонение и мы возвращаемся на опорную траекторию.



Так управлять можно, но сильно неэффективно. Почему? Потому что возвращение на опорную траекторию требует очень больших затрат, хотя не всегда есть необходимость идти по первоначально намеченному плану. А когда уже появились бортовые цифровые вычислители (БЦВМ) — то был применён гибкий подход. В ракетостроении он назывался метод терминального управления.



Когда каждый раз, когда накопился некий объём отклонений (вышли из допустимой трубки траекторий), — мы не пытаемся вернуться на заранее расчитанную траекторию. А пытаемся посмотреть, а как нам лучше попасть в нашу цель из той точки, в которой мы уже находимся, может ничего не надо делать, просто прилетим пораньше? Ничего страшного. Значит аналогичный подход (привязывают его к Agile) – «планы ничто, а планирование – всё». Да мы планируем, перепланируем, и опять перепланируем, держа перед собой конечный результат (нашу цель). Всё хорошо работает, если мы чётко знаем, где у нас расположена цель, и она остаётся во время нашего полёта – на месте. В программостроении это совершенно не так, потому что, как правило, цель мы формулируем в самых общих понятиях. Прихожу я к Заказчику, спрашиваю: «Заказчик – чего ты хочешь?». «Ну, хочу информационную систему, которая принесёт мне счастье». Начинаем уточнять: «А счастье – это как? Программу и методику испытаний – как будем писать?». Да – цель меняется по ходу, требования меняются по ходу. И в системах управления ракетами возник дополнительный контор, который пытается засечь цель и изменить путь в соответсвии с новым прогнозом положения этой цели. А в современном подходе по разрботке ПО этот метод называется итерационный и инкрементальный. Когда мы максимально часто стараемся поставлять продукт заказчику для его оценки, для получения обратной связи. Т.е. мы уточняем цели.



Ну, всё это не работает, если мы плохо знаем тот объект, которым управляем. Если его структура и свойства нам недостаточно известны, либо меняются во время полёта. Значит, в ракетостроение придумали метод «адаптивного управления» — добавляется ещё один контур, помимо всех остальных, который пытается понять, это что за объект, которым мы управлеяем, построить более точную модель и более адекватно прикладывать к нему управляющее воздействие, как направление на движение в этом фазовом пространстве, так и направленные на изменние нужных для движения свойств самого объекта.



То, чем мы управляем в программном проекте, это люди и их взаимодействие. По моим многолетним наблюдениям – 50% времени разработчика ПО в среднем, уходит на переговоры. Ну понятно, — менеджеры болтают целыми днями. Программисты, тестировщики чуть-чуть поменьше, но в среднем на всех участников проекта 50% времени мы разговариваем, для того чтобы синхронизировать наши ментальные модели того, что мы делаем.
Значит вот я попытаюсь изложить вам своё виденье того, как адаптивный подход в управлении программными проектами, позволяет сделать проект любой сложности с командой обычных разработчиков. Мы будем говорить о принципах. А я постараюсь их проиллюстрировать примерами.



Один человек – Иосиф Виссарионович Сталин говорил – Если два коммуниста не могут договориться, то один из них враг… или оба.
Значит, коллеги, это первые грабли, по которыми я напрыгался вдоволь. Когда я стал, а это было достаточно рано, руководителем до 30 лет. В советские времена это было большое достижение. У меня была чёткая классификацию людей по их типам. И у меня было два типа личности:
1) Правильные люди, которые думают и делают, как я.
2) Все остальные, которых железной рукой надо привести к счастью.
Жизнь меня поправила и сейчас наиболее используемые мной типы личности включает 16 типов – это модель Майерс-Бригс. Если кто не читал – рекомендую, к программированию это очень хорошо прикладывается.
16 типов личности, тут описаны два типа личности:
— логик – Винни Пух
— этик – Пятачок
Это нормальные люди, это счастье, что Бог создал нас разными, за счёт этого мы получаем классные продукты, за счёт синергии разных взглядов на конечный результат.



Раз все люди разные, то тут возникает принцип №1. Принцип необходимого и достаточного разнообразия. Это вовсе не я придумал. Пятьдесят лет назад это написал в книге «Введение в кибернетику» Эшби. Поэтому руководитель проектов приходит к 9:00 на работу и начинает наблюдать. Потом он общается, в основном, слушая людей. Наша задача понять людей, для этого мы обязаны их слушать. А давать указания только в последнюю очередь. Анализирует, что происходит, пытается в своей практике найти что-то подобное. В адаптивной системе управления – наиболее эффективные методы построены на прецедентах. Когда в БЦВН засовывают кучу-кучу образцов. Если происходит нештатная ситуация – она начинает кейсы перебирать и искать подходящие. Аналогично работает менеджер программного проекта. Он из своего опыта достаёт два-три-четыре примера и пытается из них синтезировать какое-то решение для текущей ситуации. А чтобы понять, правильное решение или нет, естественно его надо пробовать, надо внедрять, надо обобщать и дальше всё по кругу – наблюдать- анализировать — и вот такой вот бесконечный цикл должен быть у менеджера программного проекта.



История 2. Делаем всё по правилам.
Грамотный эффективный специалист, который нацелен, мотивирован на постороение самого лучшего решения, который имеет самый быстрый алгоритм и при этом имеет минимальные ресурсы – очень любит применять все лучшие патерны, которые знает, больше всего любит применять то, что не знает, но Вася Пупкин сказал, что новая технология это крута.
Есть тут проблема? It depens…
Если мы делаем утилиту по сжатию, компрессии данных, изображения, звука, которая в 10 раз эффективней аналогов, то наверное так вот и надо поступать. Но вот, как правило, когда я встречаюсь с такого вида поведением – это паттерн, это частый вариант поведения, у кторого даже есть свое название — перфекционизм. Преждевременная оптимизация.
Я пытаюсь человека поправить. Вот чего мы делаем? Мы не разрабатываем самую лучшую в мире программу, мы программами деньги зарабатываем. И проблема данной ситуации в том, что программист не помнимает цель работы.



Принцип 2. Четыре необходимых и достаточных условия эффективной работы.
Для того, чтобы программист эффективно решил поставленную, надо чтобы он:
1) Понимал цель задачи. Чётко — деньги зарабатывать
2) Как работу делать, уметь её делать.
3) Если мы программиста заставляем писать программу – то надо дать ему часы свободного времени, ну ещё желательно компьютер, хотя по жизни мы писали и на листочках, потом сдавали в перфораторную и компьютеров не видели, но сейчас компьютер всё таки необходим. Т.е. должна быть у человека возможность решить эту задачу.
4) Задача не может быть решена за любое отведённое ей время, если у человека нет желания. Этот человек вам расскажет 101 причину, почему этот он сорвал в очередной раз срок. Если нет мотива – он не будет искать хотя бы одну возможность, которая поможет ему эту задачу порешать. Поэтому передайте задачу другому программисту, а этому дайте что-нибудь ему интересное.



История. Программист Ашманова.
Почему программист Ашманова? Он не у Ашманова работал, но есть такая статья прикольная, которая уже давно в интернете лежит, «Ненормативная лексика программистов», вот это полностью цитата оттуда.
Тоже очень типичное поведение. У меня на компьютере всё работает. Программирование это творчество, зачем его клонировать. В пятницу готового не будет, но в понедельник точно, ну или во вторник. Всё нормально, всё так бывает. Вот в ВУЗах учат нас средам, языкам программирования. Даже приходили студенты, которые знают, что такое патерны программирования. Но ни в одном ВУЗе не учат студентов работать в промышленном производстве, котороне называется разработка программного обеспечения.

Поэтому это от недостатка опыта, поэтому вспоминаем четыре необходимых и достаточных условия и соответсвенно четыре роли должен исполнять руководитель, если он хочет добиться успеха проекта.



Не понимает цели – руководить должен стать штурманом.
Не умеет делать — научи или найди другого более опытного сотрудника, который научит.
Ну, помощник обеспечивает: стул, стол, компьютер.
И, наконец, нужно уметь мотивировать людей. Это очень важно, это одна из самых сложных проблем разработки ПО. Нужно уметь вдохнавлять людей, чтобы уметь получать нужные результаты.

Следующая история – «Звездун».



Любит спорить, на всё имеет свою точку зрения. Может бесконечно отстаивать её, когда даже по глазам видно, что засомневался, но нет – он не может быть не прав. Умничает. Какие-то ненужные термины, buzz-words использует в обсуждении рабочих вопросов. Но это не самое страшное, как правило, самое страшное – что у него завышенная самооценка. Считает, что он может горбатиться на проект меньше, чем его менее квалифицированные коллеги. Вот это расхолаживающе может действовать на команду.
Как-то в Питере на одном из моих тренингов был как-то достаточно зрелый руководитель. Лет 45. И вот на все кейсы, которые я представлял, с тех пор они мало поменялись, он говорил – «уволить нафиг». Я пытался его поправить – вот этого надо учить, а вот этому цель правильную поставить. Но когда он в третий раз сказал «уволить нафиг» — коллега из другой компаний, через проход протянул ему свою визитку и сказал: «будешь увольнять – звони».



Это я к чему. Это когда одна паршивая овца мне испортит мою корзину яблок. Я лучше пожертвую одним квалифицированным игроком. Но выиграю в том, что станут более эффективные коммуникации. Будет меньше ненужных дискуссий, будет меньше переходов на личности, меньше будет споров о том, как правильно это нужно сделать, как красивее это сделать. Почему? Потому что наличие такой личности – не позволяет сложиться команде.
Все в нашей отрасли пришли к выводу, что наиболее эффективные процессы складываются в саморганизующихся, в самоуправляемых командах. Scrum, Agile методологии – всё это об этом.
Последние наработки университета Carnegie Malone – это Personal Software Process, Team Software Process. В Team Software Process написано, что основная задача – руководителя проекта в том, чтобы набрать нужных людей и заставить их работать командно. Так вот об этом ДеМарко очень много писал в своей книге Peopleware. Кто не читал – я вот даже не буду руки просить поднимать и считать – срочно идти читать. Без знания этой книги в разработке ПО, в управлении проектами уж точно делать нечего. Ну они – Де Марко и Листер писали, что не знают что делать для того, чтобы сложилась команда. Надо набрать хороших людей, поливать, удобрять и если Бог пошлёт, то команда сложится. Я, опираясь на свой опыт, могу открыть тайну – я знаю как сделать такую команду.
Не бывает лидера без команд. И за свои 50 лет не только в профессиональной области, но и в спорте, я не видел ни одной команды, вот такой Команды с большой буквы, в которой бы не было явного, ярко выраженного лидера. Цитата из любимого классика: «мы не сделали сканадала, нам вождя не доставало. Настоящих буйных мало – вот и нету вожаков»
Ещё один момент, то что важно, так просто лидером не станешь. Лидером назначить – нельзя ни в коем случае. Человек может сам стать лидером, если заслужит уважение своими профессиональынми качествами и доверие команды своими личностными качествами. Ещё цитата из другого классика: «вожак – выбирает сам себя и сам себя утверждает».

Ладно – сначала пример, прежде чем мы назовём следующий принцип.



Пример. Тихоня.

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



И вот по разному в руководители попадают люди. И давайте начнём с нижнего квадранта: нет доверия, нет профессионального признания. Когда такая ситуация возникает? Когда в какой-то сложившийся коллектив спускают «парашютиста» и говорят – он будет вашим начальником. Никто не знает ни о его опыте, ни о его человеческих качествах. И поэтому, чтобы у такого «парашютиста», ПО разрабатывалось – есть только один метод, это строгое назначение – постановка коротких задач, контроль сроков, — всё идёт довольно жёстко. Так можно управлять, но это очнеь неэффективно, поэтому обычно стремимся перейти в четвёртый квадрант.
Другая ситуация. Доверие команды – есть. Вася Пупкин – хороший програмист, заколбасил половину прошлого проекта. Менеджер прошлого проекта пошёл на повышение. Васе сказали – ну ты теперь будешь руководить. У команды – доверие есть. Потому что с Васей выпит не один пуд соли. Уверенность полная, что Вася классно знает С++, но вот то, что Вася классно умеет работать с людьми — часто это бывает совершенно разные области. Поэтому для того, чтобы Вася утвердился как профессионал, имея доверие. Он должен все свои решения продавать. Т.е. объяснять, почему именно Ваня будет решать эту задачу, почему именно в такой срок. По прежному такое довольно жёсткое управление, но плюс – объяснение.

Другая ситуация. Я пять лет назад, когда менял место работы попал в похожую. Ну, резюме моё видели на новом месте работы в общем-то, ни одного провального проекта в нём нет. Проекты большие и успешные, но команда в которую меня посадили, ни разу не знает, сколько трупов програмистов оставлено на пути моих успешных проектов. Поэтому самой главной моей задачей на первое время было опять же такое директивное управление, но надо уметь завоёвывать доверие. Ну, я не знаю другого способа, как привлекать к решению даже мелких вопросов тех людей, которых они касаются. Это такой разгул демократии, а это зло. Если бы демократия присутствовала при принятии всех решений, то мы бы ходили бы по плоской земле, которая стоит на трёх слонах, которые стоят на черепахе и так далее. Но по-другому завоевать доверие не возможно и вот опять таки со своим опытом мне удаётся выступить в роли коуча. Путём наводящих вопросов пытаюсь повернуть дискуссию в нужную мне сторону и завести так, чтобы коллеги сами приняли нужное мне решение. Но иногда этого не происходит. Да я знаю, что это путь не оптимальный. Но в такой ситуации, когда нет доверия, я не продавливаю своё решение. Ладно, пускай мы немного лишних человеко-часов потратим. Но это мои инвестиции в развитие доверия. Без доверия – нет команды. Кто-то из зарубежных коллег написал. «По уровню взаимоуважения людей в команде, я могу судить об уровне успешности проекта». Да, это верно, это так.

Ну и наконец, когда есть доверие, есть профессиональное признание команды – вступает самый мощный инструмент управления – делигирование, когда я все свои задачи раскидал. Ты передо мной отвественный и принимаешь решение в своей области. Как ты там это будешь делать – я не полезу, это всё твоё – ты за это отвечаешь, если чего – ты приходи ко мне посоветоваться. Но если это вопрос в зоне твоей компетентности – решай сам.
Ну ещё один кейс, время у нас ещё есть.

История. Менеджер должен занимать очередь.



Ни одно решение не принимается на веру. Все конфликтуют, конфликтуют большей частью по делу. Исключительно производственный характер, конфликты разрешаются достаточно грамотно и профессионально и прямая цитата из Де Марко: Менеджер проекта должен занимать очередь, чтобы постучать по голове работнику, который вчера развалил билд автосборки. Это ситуация, которая характеризует ту область, когда команда вышла на плато наивысшей производительности, когда она самоорганизовалась и уже самоуправляемая. Значит согласно теории командного образования, которая почему-то к нам идёт с Запада, хотя у нас ещё в 13-ом веке ходили по Руси производственные команды, которые назывались артелью, которые решали суперсложные вопросы хозяйственной деятельности.



Ну вот те теории, которые к нам с Запада приходят, они отражают реальность: действительно, forming, storming, norming, performing – совершенно необходимые фазы, через которые должна пройти новая команда, и даже не новая команда, вот когда команда пересаживается в новый проект и опять начинается вот этот Storming. Потому что проект новый, потому что вновь сыграли амбиции – кто-то хочет занять новую роль. И это необходимо, и надо к этому спокойно относится и руководитель должен уметь выруливать из каждой ситуации. Но если команда подянлась на плато наивысшей производительности, то долго не возможно её удержать на этом плато – почему? Потому что – всё меняется, люди меняются, проект меняется: был проект 10 000 строк кода, стал проект 250 000 строк кода. И если ничего не предпринимать, то эта команда, её производительность – свалится в болото застоя и стогнации.
Чтобы это не произошло – переодически, после завершения, после банкета, после успешной сдачи очередного релиза надо что-то в команде менять. Ну, вот сложно привести пример, в каждой команде по-своему. Но вот последняя история.

История всё достало.



Некий программист – в авторитет у коллег, в начале проекта был исключительно эффективен – предлагал супер решения, которые позволили съэкономить сотни человеко-часов на разработке. Какие-то фреймворки, open source продукты внедрял, а вот на стадии проекта, когда надо колбасить код, копать, копать и копать – начал витать в облаках, партизанщиной заниматься, какие-то новые технологии исследовать, брать себе из беклога задачки попроще и по ним в том числе срывать сроки. Это пример к тому, что вот поменялись люди в проекте, проект уже сам сменился. Это типичное поведение человека, которому комфортно исполнять роль – генератор идей. Как только основные задачи уже решены, он уже знает как их решать – ему становится не интересно, доводить формулу до числового значения – ему не интересно. Оптимальный вариант – дать такому человеку ещё более сложный проект, назначить его системным архитектором и будет всем счастье.
Это один из способов реформ, рефакторинга проектной команды.
И, наконец, последний принцип и последний слайд

Принцип 7. Принцип четырёх «П».



Моё глубокое убеждение и вся жизнь подсказывает, что, как я говорил, нет одного процесса, хорошего в любой заданный момент. Каждый проект отличается в первую очередь продуктом. Продуктом может быть социальная сеть Однокашники.ру, а может быть система управления автоматизированным ядерным реактором. Проекты – тоже разные. Многие проекты начияются с кодинга с нуля, но бывают и проекты, которые за годы своей истории накапливают миллионы строк кода и это совершенно разные проекты – когда несколько сотен тысяч строчек кода и когда миллионы…
Персонал, самое главное, что есть в каждом проекте, все старшие программисты, все ведущие программисты, все тим-лиды – они разные, по проектным ролям, по типам личности, по мотивации, по том, что их мотивирует в данный конкретный момент.
Поэтому главный тезис – что не существует одного лучшего процесса, который порешает все проблемы в проекте. И не люди должны под процесс подстраиватсья, а мы должны подстраивать процесс по конкретных людей.
В одном из восточных диноборств есть три уровня мастерства. Боюсь ошибиться, но условно скажем, называются они – шо, ха, ри.
Первый уровень мастерства – ШО – когда боец под руководством наставника изучает какой-нибудь один, самый эффективный приёмчик. Ну вот, например, Scrum. И научается побеждать большую часть своих врагов при помощи этого приёмчика. Но жизнь идёт, враги усложняются. И начинает человек понимать, что все одним приёмчиком не получится победить. Некоторые его знают и просто подножка на них не работает. И тогда он начинает смотреть вокруг и искать ещё эффективные практики. Получается у него некоторый RUP, из котого он выстраивает процесс в команде, для того, чтобы победить любого сложного игрока.
А третий уровень, это когда боец – знает всё, включает мозг и практически на автомате использует свои знания и, если в текущей ситуации нет известного эффективного решения, то быстренько изобретает и кладёт в свой личный багаж best practices.
Вот примерно так должен развиваться программный проект. Моё виденье – нет одного лучшего проекта, но есть адаптивный подход, это такой метапроцесс, который позволяет каждый раз процесс настраивать так, чтобы команда работала максимально эффективно.
И заканчивая, прежде, чем перейти в к вопросам. Небольшая реклама. Прозвучало, что у меня вышло пять книжек, в этом году надеюсь выйдет шестая, история этой книжки следующая. С группой товарищей, которая провозгласила себя Гильдией менеджеров, мы подготовили учебную программу для вузов. Вот я сказал, что в вузах не учат работать. Мы подготовили своё виденье спецкурса по управлению программными проектами, для того чтобы, приходя ко мне, студенты, понимали как индустрия ситсема управления проектами устроена, конечно менеджерами проектов они сразу стать не смогут. Но они должны понимать, кто такой руководитель проекта, какое место они занимают в этом не простом процессе. Вот пытаемся мы внедрить эту программу в умы нашей системы образования и параллельно с группой товарищей, а конкретно это Дмитрий Башакин – самй главнй эксперт по проектному управлению всея компания Люксофт, — думаю всем известная компания, сейчас если я не ошибаюсь, у них 4 500 программистов по всему миру, а Митя Башакин – это ведущий эксперт, который отвечает за управление проектами в этой компании. Следующий автор – это профессиональный психолог из Санкт-Петербурга, Ольга Одинцова пересеклись мы с ней лет пять назад, когда совместно готовили курс по эффективным коммуникациям в командах разработчиков программного обеспечения. Сейчас эти связи обновили и вместе пишем книгу. И, наконец, четвёртый автор, может быть это не самый опытный менеджер, но на мой взгляд – самый талантливый, запомните имя – Максим Дорофеев, сейчас он руководит проектами в лаборатории Касперского, в позавчерашнем письме он написал, что сильно занят, какое-то повышение получил, ну не знаю какое, в частности вся книжка будет оформленна вот такими рисуночками – это его творчество – прошу любить и жаловать.
Автор: @Polazhenko
Лаборатория тестирования
рейтинг 26,69
Компания прекратила активность на сайте

Комментарии (13)

  • +4
    Спасибо. Это один из самых полезных резюмирующих текстов по управлению проектами.
  • 0
    Текста много…
    Стоит читать?
    • 0
      Прочитал… Очень понравилась статья, спасибо!
      • 0
        За 5 минут?
        • 0
          эм… пост опубликован 3 ноября 2011, 19:06, комментарий выше 3 ноября 2011, 21:30. Тут вроде как два с половиной часа разница.
          • 0
            Посмотрите на времена двух предыдущих комментариев и сделайте вывод.
            • 0
              упс, мой косяк. Не заметил что это были посты одного полльзователя.
  • 0
    Неплохая статья из стенограммы получилась.
    Доклад обычно лучше воспринимается чем художественная статья
  • +2
    Очень понравилось. С одной стороны ничего нового, с другой — хорошо сформулировано. Жалко мало — явно неполлная лекция
  • 0
    Хорошо написано, и картинки тоже понравились.
  • +1
    Есть анекдот. Приходят мыши к мудрому филину и говорят — «нас все обижают, что нам делать?». Мудрый филин подумал, подумал, и сказал им — «станьте ежиками!». Мыши, обрадованные убежали, но через некоторое время вернулись назад. «А как нам стать ёжиками, о мудрый филин?» — спросили они. «Не знаю, я — стратег», ответил им филин.

    Еще можно добавить, что управлять людьми нельзя. Нельзя не только потому что невозможно, но и потому что это запрещено (уже давно). Управлять следует процессами (привлечения в проект в том числе), потому что они, а не люди, приводят к результату.

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

    В общем, многие зарубежные best practices (PMBoK например, в области знаний управления персоналом проекта в частности) в ряде вещей говорят обратное высказанному, как бы красиво оно не выглядело, при всём уважении.
    • 0
      Процессы без людей сами по себе ничего не стоят. Разумеется, процессами надо управлять. Но ни один процесс не даст результата, если люди его не воспринимают. По вашей логике привлечением в проект людей управление ими ограничевается?

      Что бы ни говорили PMBoK, CMMI и другие (а про людей они действительно почти не вспоминают), руководство процессами без грамотного управления командой всегда будет менее эффективным, чем с ним.

      Кроме того, если одна система уже прошла этот путь развития модели управления (управление ракетами), то с большой вероятностью УП пройдет такой же путь. В этом смысле современные стандарты управления являются промежуточным шагом.
  • 0
    Хм. Есть мнение, что если компания и команда, не останавливается сделав 20% работы и получив 80% результата — то все разговоры в которых используется слово «эффективно» в разных формах, не более чем bull-shiting.

    Ещё немного смущает заголовок, в части «адаптивного управления». А как может быть какое-то другое?.. Даже в том же водопаде, никто не запрещает корректировать курс при появлении новых обстоятельств.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разное