Читал 2 книги : "Catastrophe Disentanglement: Getting Software Projects Back on Track", E. M. Bennatan
и "How To Run Successful Projects III: The Silver Bullet" Fergus O'Connell.
Сразу скажу, что первая была как-то интереснее наличием последовательных шагов, рекомендации и прочими полезными ништяками, вторую читал почти через силу и потому отзыв будет достаточно скептичным.
Не секрет, что в отрасли разработки ПО затянувшиеся сроки, раздувшиеся бюджеты, периодические авралы и прочие увлекательные вещи не такие уж необычные вещи. "Shit happens" как говориться =)
Мне приходилось участвовать в таких проектах, вам приходилось, ну и в общем-то статистика (например по опросам standish group) сводиться к тому что-то около трети проектов считаются себя успешными (т.е. не сильно вышли за сроки, бюджет, и адекватны требованиям и с небольшим количеством багов). В общем поучаствовать в таком проекте придется еще и думаю не раз. В общем результате таких измышлений поставил себя в план почитать о том, как выбираются из жо**итеских проблем.
В общем-то ее можно бы свести к одной фразе "Остановитесь и подумайте как так получилось, а потом составьте план исправления", а все остальное можно считать уже последствиями.
Ключевое слово здесь - "Остановитесь". Т.е. реально перестаньте делать вобще ВСЕ виды работ, чтобы до всех дошло, что у проекта действительно серьезные проблемы и их сейчас будут решать и надо бы этому поспособствовать. Т.к. пока проект идет - "дело то делается, через неделю все готово ж будет", хотя неделя уже может идти вот который месяц.
Следующий шаг - "назначаем оценщика(Evaluator)", т.е. находим его, становимся сами или еще что, желательно со стороны чтоб мог придти и спокойна сказать - "да у вас тут батеньники - *#%№!" своим чистым и незамутненным взглядом, а то внутреннему человеку сложно это сказать, т.к. руководство по голове не погладит да и коллеги могут не понять такой формулировки.
Ну а дальше по накатанной: оцениваем проект(сроки, отчетность, планы и т.д.), оцениваем команду(они вобще работали, или может в варкрафт гоняли, а пм вобще мотивировал их или жаловался на жизнь, там вобще есть команда ? или 50 распределенных по всему свету индусов).
И выделяем "минимально допустимые цели"(аналог MVP из agile(product-development) практик). Т.е. вместо создания комбайна делающего все и вся пытаемся создать инструмент делающий хоть что-то полезное.
А теперь - проверяем а минимальные то цели достижимы ? Может быть идея создания искусственного интеллекта для тостера не была таким уж и выполнимым проектом ?
Ведь вполне может оказаться, что поставили себе цели - "захватить мир", а сил и ресурсов даже на захват отдельно взятой банановой республики нет.
Если решили что цели то в принципе еще достижимы то пересобираем команду, это и дух моральный поднимет (они уже не те лузеры, что завалили проект изначально) и поможет поправить какие-то конфликты\проблемы в команде.
Следующий шаг - делаем анализ рисков, что может опять пойти не так ? Как это можно починить\сгладить, вполне возможно чтоб если в первый раз проект проанализировали на риски, то не пришлось бы его вытаскивать из той катастрофы в которую он попал.
Осталось то всего - пересоздать план, который достижим с учетом тех данных, что есть на текущий момент.
И наверное самое главное, что я почерпнул из этой книги - создать систему раннего предупреждения. Ведь проект не приходит в состояние катастрофы - "внезапно", как говорит Брукс: "How does a large software project get to be one year late? Answer:One day at a time!".
Т.е. начинать хвататься за голову уже когда прошли одна треть или две десятых проекта, а уже начался перерасход планируемого бюджета сроков и прочего, а не надеяться на "в конце поднапряжемся и доделаем". В общем-то тоже что и с рисками, надо было это сделать до начала проекта. А после того как проект перешел в стадию "чиним", это уже не система раннего предупреждения, а способ не повторить той же ошибки.
Но есть один тонкий момент, некоторое время проект может "стабилизироваться" после перезапуска и в своем начале, потому система раннего предупреждения должна вступать в силу через некоторый "льготный" период, дабы она сразу не сработала.
Ну и собственно "запускаем" и не забываем провести послепроектное ревью, чтоб убедиться что в следующий раз вы сделает только новые ошибки)
Итого:
В общем книжка интересная подробным планом, и секциями "What can go wrong ?" на каждом этапе и рассмотрение основных проблем + способов их решения, + идея early warning system, которая часто применяется в средствах мониторинга за серваками, так же применима и к проектам.
Если честно в книжке еще множество моментов, типа как выбирать оценщика(неплохо бы чтоб это был известный консультант с медалями и прочим), или в каких случаях еще можно побороться с сопротивлением, а в каких стоит сразу идти к стейкхолдеру процесса переоценки и починки, т.к. без его вмешательства проект может заглохнуть, но все их рассматривать нет смысла и желанья, просто помните, что когда в следующий раз вы будете думать, что проект "попал" - то это отчасти поправимо, и есть подробная инструкция как это делается =)
Серебрянная пуля
Следующая книга, бывшая в планах на июль - "Серебрянная Пуля"(How To Run Successful Projects III: The Silver Bullet) О`Коннела.
Такое наверно слегка наивное повествование в стиле, "вот те 10 шагов, которые выработались у меня и моих коллег со временем и делая их мы гарантируем ваш успех".
Странно, что проекты до сих пор заваливают, хотя книга достаточно известная, да и думаю если б она гарантировала 100% успех, то ее знание бы стояла в требованиях во всех PM`ких вакансиях. Но тем неменее шаги и мысли в общем, то имеют некий базис и практическую пользу.
Еще в книге есть такой забавный фактор типа PSI(Project Success Indicator), и чем ближе он к 100 тем лучше, книга написана в эдаком PMBOK-PM стиле: сначала мы все запланируем, а потом выполним план досконально и придем к успеху. И в итоге поделена на две части : планируем(первые 5 шагов) и выполняем(последние 5 шагов). И распределение шанса на успех 70% к 30%, т.е. сначала надо сильно-сильно все запланировать, иначе - можно проект и не начинать.
Хотя, как я уже упоминал шаги неглупые и достаточно полезные.
И так по порядку:
1) Визуализируем цель.
Определяем кому, зачем и как надо получить готовый проект. Можно и нужно применить метод "The and-they-all-lived-happily-ever-after method", т.е. определить критерии достижимости цели и всякие такие полезные штуки. На самом деле действительно очень важная вещь, Макс Дорофеев в своем блоге приводил видео, в котором Сергей Мартыненко подробно обьяснял почему это действительно важно. Ну и visual management - это наше все и действительно удобно.
2) Делаем список работ, которые должны быть сделаны.
И ведь не поспоришь же.
3) Должен быть только 1 лидер
Остаться должен только один! (с) Горец
Тоже, не вызывающий споров пункт.
4) Назначаем людей к работам
Вот это кстати интересный пункт, не редко встречается список: надо бы сделать и подразумевается, что делать это будет тот, кто к этому моменту будет свободен. Т.е. кто ответсвенен и кто будет решать ту или иную задачу достаточно долгое время будет не известно.
А вдруг окажется, что нет человека обладающего необходимыми навыками ? А учитывает ли другую работу, на которой может быть занят работник этот план ? Может его еще надо найти. Да и назначение типа: "написать модуль приема заказов - работник 1" , "написать модуль отсыла заказов - работник 2" - ни о чем не говорят.
5) Управляйте ожиданиями, имейте запас на ошибку, имейте позицию для отступления.
Второй интересный пункт, в общем-то практически всегда, что-то идет не так, и запас времени на ошибки надо закладывать, если ваша организация позволяет это делать в открытую - так и делайте, иначе можно добавлять задачи типа "оптимизация работы с памятью" и другие задачи "для виду", чтобы иметь возможность наверстать упущенное. Так же неплохо иметь какой-то запасной план, а то мало-ли система не справиться с нагрузками, в момент запуска будет найден, критичный баг и т.д., и иметь запасной вариант на этот случай - необходимо, может обратно включиться текущая система, или не будет работать часть функционала, что-угодно лишь бы сбой запуска системы не стал ее концом.
6) Используйте адекватный стиль лидерства.
Довольно подробный параграф о стиля лидерства, в ближайшее время выложу mind-map про команды и ситуационное лидерство в частности, так вот это о нем, немного другими словами но мысль тажа) Можно загуглить если вы первый раз слышите)
7) Знаем, что происходит на проекте.
В общем идея, того что мы проверяем что проект идет по плану, и как-то реагируем если где-то фейл. Собираем отчеты, фидбэк, отлавливаем признаки когда что-то не так. Думаю раскрывать особо нет смысла.
8) Рассказываем людям, что происходит
Данный пункт относиться и к команде и к заказчикам, руководство и т.д. Опять же пятничные отчеты, общение с командой, ничего фантастически нового.
9) Повторяем шаги с 1 по 8 пока не шаг 10.
Просто и гениально =)
10) Собираем приз, получаем награды, награждаем участников.
Собственно то, ради чего все и затевалось)
По автору все это: не сущей воды пустяки, но хотя бы накатанyый процесс.
Это было описание первой части =)
В следующих частях уже раскрываются какие-то общие вещи: как это масштабировать на несколько проектов, как проверять корректность составленных планов, как набирать персонал, вести переговоры и устраивать встречи, как разбираться с проблемами, стрессом и прочими прелестями менеджерской жизни.
В основном - все обзорные пункты(basics(tm)), и потому чего-то нового в них нет. Можно просмотреть для ознакомленния и все.
Плюс последняя треть книги это всякого рода приложения типа "Процедура оценки ISO 9000", которые мне как-то не особо хотелось читать, хотя возможно в них гораздо больше пользы чем в во всей книге.
Итого:
C одной стороны книжка вроде не бесполезная, и знание о стилях лидерства дадут например полезные знания, но с другой стороны с текущим agile-майнстримом, убеждения вроде можно все спланировать заранее и потом просто сделать вызывают не иллюзорные сомнения. Можно ознакомиться, чтоб знать как оно должно делаться в более-менее годном ватерфолле, с другой стороны есть пункт 9, которые хитро превращает весь процесс в итеративный =)
Комментариев нет:
Отправить комментарий