Решите, что в практике работы было хорошим, а что оказалось негодным; что заслуживает особого внимания на следующем этапе, а от чего следует отказаться. Следует отметить, что такого рода «самокопание» полезно для всей проектной команды, и тот факт, что их опыт будет полезен для будущих команд безнадёжных проектов, может подсластить пилюлю. Кроме того, такое подведение итогов в конце этапа обычно поднимает дух команды, их суждения становятся более оригинальными, искренними и не такими циничными.
Что же касается организаций, которым недоступен положительный опыт других команд, то я бы порекомендовал несколько источников. Данная тема затронута в одной из глав моей книги Rise and Resurrection of the American Programmer ; другие материалы, касающиеся наилучшей практики, можно найти на сайте консультанта Кристины Комафорд Возможно, наиболее амбициозным проектом, находящимся в настоящее время в процессе разработки, является проект министерства обороны США, информацию о котором можно найти на сайте http://spmn.com.
Ниже перечислены «наилучшие практики», рекомендуемые в этом проекте (не забывайте данный мною ранее совет о том, что не следует воспринимать эту информацию буквально как «заповедь», которой необходимо следовать; наоборот, она может служить полезной отправной точкой для ваших собственных идей относительно наилучшей практики):
20) Формальное управление рисками — я буду обсуждать его позже в данной главе.
21) Согласованные интерфейсы — аппаратные интерфейсы, программные интерфейсы и интерфейсы между вашей системой и другими внешними системами.
22) Экспертные оценки — экспертизы, проверки, сквозной контроль. Это весьма распространённая и понятная практика, однако в безнадёжных проектах от неё зачастую отказываются, поскольку считают, что это затормозит работу. В принципе, большинство из нас понимает полезность таких экспертиз, но в экстремальных условиях безнадёжных проектов каждый успевает только делать своё дело, и ему не до того, чтобы показывать свою работу остальным участникам команды.
23) Планирование и управление, основанное на метриках — речь идёт о том, что в основу наших планов и оценок должны быть положены данные, накопленные в предыдущих проектах. Однако, как было сказано выше, предыдущих безнадёжных проектов может просто не быть, а если даже они и были, маловероятно, чтобы кто-нибудь позаботился записать какие-либо полезные данные (кроме подсчёта потерь, понесённых командой). Все же, если имеются в распоряжении какие-либо данные, полученные в «нормальных» проектах, их можно было бы использовать для выверки оценок, сделанных в безнадёжном проекте — хотя бы для того, чтобы убедиться в их безумной оптимистичности!
24) Бинарная оценка качества по результатам этапов — другими словами, вместо того, чтобы заниматься подведением итогов каждые три месяца, во время которых команда рапортует, что она написала 97 процентов кода, следует подводить промежуточные итоги еженедельно, или даже ежедневно , фиксируя достигнутые результаты с помощью «бинарных» признаков. Одним из способов выполнения этого является стратегия «ежедневного завершения проекта», которая обсуждается в следующем разделе.
25) Свободный доступ к информации о проектных планах и фактических результатах — это согласуется с моими рекомендациями в предыдущих главах. Безнадёжный проект будет испытывать достаточно большие трудности, если менеджер будет скрывать от остальной команды информацию о состоянии проекта.
26) Фиксация дефектов в соответствии с заданными показателями качества — одна из идей данного проекта заключается в том, что дефекты идентифицируются, фиксируются и устраняются на ранних стадиях процесса разработки. Это позволяет не только точно установить уровень дефектности в разработанной системе, но и устранять дефекты в тот момент, когда стоимость их устранения относительно невелика, а не дожидаться стадии тестирования системы.
27) Конфигурационное управление — как бы оно не называлось (контроль версий, контроль исходных кодов, или как-нибудь ещё), конфигурационное управление обычно рассматривается как важная практическая составляющая проектов, протекающих в экстремальных условиях.
28) Ответственность и подотчётность руководства перед сотрудниками — увы, но в большинстве безнадёжных проектов этому моменту не уделяется достаточно внимания; как было отмечено выше, многие безнадёжные проекты относятся к типу «самоубийственных» или «камикадзе».
Одно из наиболее значительных достижений данного проекта министерства обороны — это понятие наихудшей практики ; особенно хорошо оно применимо к безнадёжным проектам, где зачастую бывает более важно предотвращать катастрофы, а не заниматься поисками наилучшего решения проблем. Список таких практик приведён ниже:
29) Не следует ожидать более чем 10-процентного сокращения сроков по сравнению со среднестатистической нормой для аналогичных проектов — разумеется, если вы действительно в это верите, то не следует даже и начинать безнадёжный проект!
30) Не пытайтесь использовать новую технологию как средство для сокращения сроков — у вас будет и без того достаточно проблем кроме отлавливания ошибок в бета-версиях новых средств и технологий, добытых у знакомого поставщика. Более детально этот вопрос будет обсуждаться в главе 6.
31) Не навязывайте заказчику решения, специфичные только для него — полезный совет для любого проекта.
32) Не следует заниматься поиском панацей — об этом стоит вспомнить, когда ваше руководство (сразу же после визита очередного настойчивого поставщика!) предлагает использовать для «спасения» проекта какое-нибудь «поражающее воображение» средство или методологию разработки.
33) Не упускайте возможность удалить из критического пути те элементы, которые находятся вне сферы вашего контроля — если ваша проектная команда не в состоянии их контролировать, то иметь такие элементы на критическом пути означает повышенную степень риска. Это относится к таким вещам, как инструментальные средства поставщика, оборудование, программные продукты и другие компоненты, поступающие от внешних поставщиков. Это касается также вещественных результатов деятельности и политических решений акционеров и заинтересованных лиц, имеющих отношение к проекту.
34) Не следует ожидать точной оценки состояния проекта от чисто формальных оценок, выполненных множеством чересчур активных и некомпетентных критиков — проектная команда не должна об этом беспокоиться, поскольку она уже знает , что такие сеансы оценки представляют собой политические ритуалы. Этот совет предназначен скорее для руководителей высокого уровня, которые наблюдают за безнадёжным проектом с безопасного расстояния, пытаясь при этом определить, в каком состоянии он находится.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59
Что же касается организаций, которым недоступен положительный опыт других команд, то я бы порекомендовал несколько источников. Данная тема затронута в одной из глав моей книги Rise and Resurrection of the American Programmer ; другие материалы, касающиеся наилучшей практики, можно найти на сайте консультанта Кристины Комафорд Возможно, наиболее амбициозным проектом, находящимся в настоящее время в процессе разработки, является проект министерства обороны США, информацию о котором можно найти на сайте http://spmn.com.
Ниже перечислены «наилучшие практики», рекомендуемые в этом проекте (не забывайте данный мною ранее совет о том, что не следует воспринимать эту информацию буквально как «заповедь», которой необходимо следовать; наоборот, она может служить полезной отправной точкой для ваших собственных идей относительно наилучшей практики):
20) Формальное управление рисками — я буду обсуждать его позже в данной главе.
21) Согласованные интерфейсы — аппаратные интерфейсы, программные интерфейсы и интерфейсы между вашей системой и другими внешними системами.
22) Экспертные оценки — экспертизы, проверки, сквозной контроль. Это весьма распространённая и понятная практика, однако в безнадёжных проектах от неё зачастую отказываются, поскольку считают, что это затормозит работу. В принципе, большинство из нас понимает полезность таких экспертиз, но в экстремальных условиях безнадёжных проектов каждый успевает только делать своё дело, и ему не до того, чтобы показывать свою работу остальным участникам команды.
23) Планирование и управление, основанное на метриках — речь идёт о том, что в основу наших планов и оценок должны быть положены данные, накопленные в предыдущих проектах. Однако, как было сказано выше, предыдущих безнадёжных проектов может просто не быть, а если даже они и были, маловероятно, чтобы кто-нибудь позаботился записать какие-либо полезные данные (кроме подсчёта потерь, понесённых командой). Все же, если имеются в распоряжении какие-либо данные, полученные в «нормальных» проектах, их можно было бы использовать для выверки оценок, сделанных в безнадёжном проекте — хотя бы для того, чтобы убедиться в их безумной оптимистичности!
24) Бинарная оценка качества по результатам этапов — другими словами, вместо того, чтобы заниматься подведением итогов каждые три месяца, во время которых команда рапортует, что она написала 97 процентов кода, следует подводить промежуточные итоги еженедельно, или даже ежедневно , фиксируя достигнутые результаты с помощью «бинарных» признаков. Одним из способов выполнения этого является стратегия «ежедневного завершения проекта», которая обсуждается в следующем разделе.
25) Свободный доступ к информации о проектных планах и фактических результатах — это согласуется с моими рекомендациями в предыдущих главах. Безнадёжный проект будет испытывать достаточно большие трудности, если менеджер будет скрывать от остальной команды информацию о состоянии проекта.
26) Фиксация дефектов в соответствии с заданными показателями качества — одна из идей данного проекта заключается в том, что дефекты идентифицируются, фиксируются и устраняются на ранних стадиях процесса разработки. Это позволяет не только точно установить уровень дефектности в разработанной системе, но и устранять дефекты в тот момент, когда стоимость их устранения относительно невелика, а не дожидаться стадии тестирования системы.
27) Конфигурационное управление — как бы оно не называлось (контроль версий, контроль исходных кодов, или как-нибудь ещё), конфигурационное управление обычно рассматривается как важная практическая составляющая проектов, протекающих в экстремальных условиях.
28) Ответственность и подотчётность руководства перед сотрудниками — увы, но в большинстве безнадёжных проектов этому моменту не уделяется достаточно внимания; как было отмечено выше, многие безнадёжные проекты относятся к типу «самоубийственных» или «камикадзе».
Одно из наиболее значительных достижений данного проекта министерства обороны — это понятие наихудшей практики ; особенно хорошо оно применимо к безнадёжным проектам, где зачастую бывает более важно предотвращать катастрофы, а не заниматься поисками наилучшего решения проблем. Список таких практик приведён ниже:
29) Не следует ожидать более чем 10-процентного сокращения сроков по сравнению со среднестатистической нормой для аналогичных проектов — разумеется, если вы действительно в это верите, то не следует даже и начинать безнадёжный проект!
30) Не пытайтесь использовать новую технологию как средство для сокращения сроков — у вас будет и без того достаточно проблем кроме отлавливания ошибок в бета-версиях новых средств и технологий, добытых у знакомого поставщика. Более детально этот вопрос будет обсуждаться в главе 6.
31) Не навязывайте заказчику решения, специфичные только для него — полезный совет для любого проекта.
32) Не следует заниматься поиском панацей — об этом стоит вспомнить, когда ваше руководство (сразу же после визита очередного настойчивого поставщика!) предлагает использовать для «спасения» проекта какое-нибудь «поражающее воображение» средство или методологию разработки.
33) Не упускайте возможность удалить из критического пути те элементы, которые находятся вне сферы вашего контроля — если ваша проектная команда не в состоянии их контролировать, то иметь такие элементы на критическом пути означает повышенную степень риска. Это относится к таким вещам, как инструментальные средства поставщика, оборудование, программные продукты и другие компоненты, поступающие от внешних поставщиков. Это касается также вещественных результатов деятельности и политических решений акционеров и заинтересованных лиц, имеющих отношение к проекту.
34) Не следует ожидать точной оценки состояния проекта от чисто формальных оценок, выполненных множеством чересчур активных и некомпетентных критиков — проектная команда не должна об этом беспокоиться, поскольку она уже знает , что такие сеансы оценки представляют собой политические ритуалы. Этот совет предназначен скорее для руководителей высокого уровня, которые наблюдают за безнадёжным проектом с безопасного расстояния, пытаясь при этом определить, в каком состоянии он находится.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59