Если вы в самом деле начинаете первый в организации безнадёжный проект, то, вероятно, самое лучшее, что вы можете сделать — это документально фиксировать все реально работающие процессы, которые могли бы пригодиться в последующих безнадёжных проектах. Один из способов сделать это — провести «ревизию» в самом конце проекта. Тем не менее, это делается редко, и результаты обычно настолько неинтересны, что никому неохота их читать. Причины этого очевидны: как было отмечено выше, проектная команда к концу проекта находится в таком измочаленном и потрёпанном состоянии, что предложение документально описать их опыт будет скорее всего встречено градом насмешек; кроме того, многие из тех, кто внёс наибольший вклад в работу, к концу проекта уже давно исчезли.
Таким образом, альтернативой может быть серия «мини-ревизий» в течение всего проекта. Если ваша работа состоит из мини-этапов, таких, как передача новой версии прототипа пользователю, запланируйте полдня на проведение мини-ревизии сразу после окончания этапа. Решите, что в практике работы было хорошим, а что оказалось негодным; что заслуживает особого внимания на следующем этапе, а от чего следует отказаться. Следует отметить, что такого рода «самокопание» полезно для всей проектной команды, и тот факт, что их опыт будет полезен для будущих команд безнадёжных проектов, может подсластить пилюлю. Кроме того, такое подведение итогов в конце этапа обычно поднимает дух команды, их суждения становятся более оригинальными, искренними и не такими циничными.
Что же касается организаций, которым недоступен положительный опыт других команд, то я бы порекомендовал несколько источников. Данная тема затронута в одной из глав моей книги Rise and Resurrection of the American Programmer ; другие материалы, касающиеся наилучшей практики, можно найти на сайте консультанта Кристины Комафорд Возможно, наиболее амбициозным проектом, находящимся в настоящее время в процессе разработки, является проект министерства обороны США, информацию о котором можно найти на сайте http://spmn.com.
Ниже перечислены «наилучшие практики», рекомендуемые в этом проекте (не забывайте данный мною ранее совет о том, что не следует воспринимать эту информацию буквально как «заповедь», которой необходимо следовать; наоборот, она может служить полезной отправной точкой для ваших собственных идей относительно наилучшей практики):
20) Формальное управление рисками — я буду обсуждать его позже в данной главе.
21) Согласованные интерфейсы — аппаратные интерфейсы, программные интерфейсы и интерфейсы между вашей системой и другими внешними системами.
22) Экспертные оценки — экспертизы, проверки, сквозной контроль. Это весьма распространённая и понятная практика, однако в безнадёжных проектах от неё зачастую отказываются, поскольку считают, что это затормозит работу. В принципе, большинство из нас понимает полезность таких экспертиз, но в экстремальных условиях безнадёжных проектов каждый успевает только делать своё дело, и ему не до того, чтобы показывать свою работу остальным участникам команды.
23) Планирование и управление, основанное на метриках — речь идёт о том, что в основу наших планов и оценок должны быть положены данные, накопленные в предыдущих проектах. Однако, как было сказано выше, предыдущих безнадёжных проектов может просто не быть, а если даже они и были, маловероятно, чтобы кто-нибудь позаботился записать какие-либо полезные данные (кроме подсчёта потерь, понесённых командой). Все же, если имеются в распоряжении какие-либо данные, полученные в «нормальных» проектах, их можно было бы использовать для выверки оценок, сделанных в безнадёжном проекте — хотя бы для того, чтобы убедиться в их безумной оптимистичности!
24) Бинарная оценка качества по результатам этапов — другими словами, вместо того, чтобы заниматься подведением итогов каждые три месяца, во время которых команда рапортует, что она написала 97 процентов кода, следует подводить промежуточные итоги еженедельно, или даже ежедневно , фиксируя достигнутые результаты с помощью «бинарных» признаков. Одним из способов выполнения этого является стратегия «ежедневного завершения проекта», которая обсуждается в следующем разделе.
25) Свободный доступ к информации о проектных планах и фактических результатах — это согласуется с моими рекомендациями в предыдущих главах. Безнадёжный проект будет испытывать достаточно большие трудности, если менеджер будет скрывать от остальной команды информацию о состоянии проекта.
26) Фиксация дефектов в соответствии с заданными показателями качества — одна из идей данного проекта заключается в том, что дефекты идентифицируются, фиксируются и устраняются на ранних стадиях процесса разработки. Это позволяет не только точно установить уровень дефектности в разработанной системе, но и устранять дефекты в тот момент, когда стоимость их устранения относительно невелика, а не дожидаться стадии тестирования системы.
27) Конфигурационное управление — как бы оно не называлось (контроль версий, контроль исходных кодов, или как-нибудь ещё), конфигурационное управление обычно рассматривается как важная практическая составляющая проектов, протекающих в экстремальных условиях.
28) Ответственность и подотчётность руководства перед сотрудниками — увы, но в большинстве безнадёжных проектов этому моменту не уделяется достаточно внимания; как было отмечено выше, многие безнадёжные проекты относятся к типу «самоубийственных» или «камикадзе».
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 60 61 62 63 64 65 66 67 68 69 70 71