Отправляет email-рассылки с помощью сервиса Sendsay

Разработка проектов и управление командой разработчиков

Рассылка закрыта

При закрытии подписчики были переданы в рассылку "Левитас: Больше денег от Вашего бизнеса" на которую и рекомендуем вам подписаться.

Вы можете найти рассылки сходной тематики в Каталоге рассылок.

←   Июнь 2004   →
 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
Автор
Александр Левитас

Статистика

2.032 подписчиков
-1 за неделю
←   Все выпуски   →

Разработка проектов и управление командой разработчиков


Информационный Канал Subscribe.Ru

Здравствуйте, уважаемые подписчики!

 

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

 

Все было просто и ясно: надо разработать то-то и то-то и я искал, пробовал и применял различные подходы. У меня тогда было мнение, что документация – это скучно, а на счет тестирования – пока пишешь сам и отладишь.

 

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

 

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

 

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

 

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

 

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

 

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

 

Правильно. Зачем обновлять спецификацию, когда есть менеджер проекта – ее реализатор. Все вопросы к нему – он ведь ходячая спецификация, вот пусть и отвечает на вопросы.

 

Но когда такой человек уходит из проекта, то проект практически умирает. И все начинается с начало: никому не нужное описание того, как работала система раньше, потом сейф, потом программирование, программирование и опять программирование.

 

Работая в государственной организации, я так и не понял, зачем делать спецификации, если их судьба – сейф. И только потом дошло, что назначение и использование спецификации там было просто искажено.

 

Я помню время, когда мы с ребятами честно очень старались сделать единый шаблон на спецификацию для всех проектов. Из наших стараний получился монстр на 20 с лишним станиц только глав и подразделов. В итоге судьба такого документа – мусорка. Такой документ не помогал в работе, а только усложнял процесс разработки – никто точно не мог сказать, что в какую главу писать.

 

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

 

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

 

На данный момент я использую в работе следующие назначения функциональной и технической спецификаций.

 

Функциональная спецификация – это документ, который является основным источником о том, как должен работать и выглядеть проект. А так же эта спецификация отражает самые последние и лучшие идеи и решения менеджеров, разработчиков и дизайнеров. Ответственен за спецификацию только один человек. Может быть, ответственна и группа людей, если проект очень велик, но даже в этом случае каждый из группы должен отвечать за отдельную часть документа.

 

Техническая спецификация – это документ технических специалистов, таких как архитектор БД, администратор, руководитель разработки, программист.

Для обоих этих документов используется более или менее произвольный вид.

 

Да, конечно можно создать универсальный формат, но пожалейте своих менеджеров и разработчиков, которые будут ломать голову, в какую из глав вашего замечательного документа вставить нужную информацию.

 

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

 

Функциональная спецификация на один из текущих моих проектов сейчас занимает более 300 страниц. Она постоянно используется руководителями разработки, разработчиками, тестировщиками, группой маркетинга и техническими писателями. Она обновляется практически ежедневно и выкладывается на сервер для всей команды и является единым документом по разработке проекта. Возможно, возникает вопрос «почему эта спецификация все еще не в сейфе?» - не помещается J.

 

Я отвечу на этот вопрос в следующих выпусках.

С уважением,

Сергей

prj_management@list.ru

 

 

http://subscribe.ru/
E-mail: ask@subscribe.ru 		Отписаться
Убрать рекламу

В избранное