Остаться в живых.

Прочитал очередную классику научной-фантастики современного менеджмента ит-проектов книгу Стива Макконела "Остаться в живых! Руководство для менеджеров программных продуктов".

Общее впечатление:

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

В рамках последних тенденций ажайла\лина и прочих "гибких" методологий довольно бюрократичная, не PmBOK конечно, но вполне себе увесистая. Что-то вроде PmBOK Light Edition =)

Некоторые из этих бюрократизмов несут довольно зрелое зерно, например интересной показалась идея именно выделенной "change control board", т.е. наличие выделенной команды, которая ответственна за внесение изменении и главное отслеживание их и ведение некоторого перечня, потому как уж очень часто встречается, что почему так сделано никто уже не помнит: "Sad, but true".

Суть книги в двух словах:
Лучше сразу делать процесс, и "наш процесс (tm)".

Как обычно

Как надо

В начале тяжелый процесс будет действительно отедать 30-40 % полезного времени. Но это лучше, чем альтернатива: чем дольше идет разработка, тем больше времени начинает уходить на "trashing" (т.е. пропадать впустую из-за бардака). И в процессе фиксинга бардака начинает появляться Процесс, который тоже отъедает полезное время.

И, ВНЕЗАПНО, оказывается, что проект на полезную работы отводиться ровно 0% времени.

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





Что было интересного: 

В книге приводиться чеклист (survival checklist): это возможность оценить по нескольким пунктам насколько высока вероятность успешного завершения проекта, каждый раз, как я считаю на моих работах получается, что лучше бы проект и не начинали или хотя бы 5-% на 50%, но все таки живут они как-то =). Хотя с другой стороны это хороший такой пример: TODO, что надо бы учесть и о чем не забыть. Можно иногда пробегать глазами, чтоб знать чего.

Хотя с другой стороны вопросы типа: "Does the project have detailed, written architecture and design documents?" как-то идет вразрез с теми же ажайл-принципами типа "don't overengineer ahead of time". Довольно неоднозначно это все, но взглянуть все таки стоит.

Пост с ссылкой на чеклист от Максима Дорофеева.

Еще показалась интересной техника defect seeding, как средство проверки качественности тестирования. Из названия ясно, что в разные места намеренно вставляются легко-исправляемые ошибки, и дабы определить сколько всего ошибок в софте.

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


Плюс интересной показалась еще одна идея: по окончанию проекта посмотреть и записать, что же было хорошо, а что же плохо -  эдакие МЕГА-ретроспективы. Мысль эта кажется, простой и очевидной, но к своему стыду нигде не применял сам и не видел, чтоб это применялось. Зачастую мы вынуждены ходить по тем же граблям раз за разом.

Итого:
Как первая книжка про software project management была-бы хороша, но если что-то уже читали более-менее серьезное, то максимум -  пробежать глазами и посмотреть, что же можно применить у себя + выписать чеклист, посчитать вероятность удачи, и посмотреть что же нужно исправить.

P.S. Книжку читал на языке оригинала поэтому цитаты на английском.