Участник:ArmorAdmin/Работа с заказчиком
Не парь заказчику мозги
Заказчик по определению не специалист в области программирования, тем более, в области руководства и аналитики программных проектов. Нет, бывают конечно исключения, но исходить надо из этого — заказчик не знает как правильно разрабатывать программы, но он специалист в своей предметной области и именно этим и должен быть ценен для разработчика и проекта.
Посему, не парь мозги заказчику своими заморочками, связанными с твоим субъективным пониманием того, как правильно писать программы и управлять эти процессом. Да, работать с заказчиком надо постоянно, встречаться как можно чаще но говорить не о будущей программе, а о той работе, которой он, заказчик, занимается. За первый месяц работы ты должен стать таким же врачом, каким врач-заказчик стал за пять лет учёбы и десять лет работы; таким же прокурором, каким стал прокурор-заказчик за… и т. д., и т. п.
Планирование
Вы не задумывались, почему практически любая интеллектуальная деятельность начинается с вопросов общего характера, а потом идет постепенное погружение в детали? Очень просто, если начать с деревьев, то потом можно не увидеть лес. Об этом знали даже наши далёкие предки.
Так обучение начинается с вводного курса, а каждое занятие с оглашения темы занятия и списка тех вопросов, которые будут рассмотрены. Проектирование танка начинается с общей компоновки и только потом идет переход к частной компоновке отделений танка, к агрегатам и узлам, размещенным в этих отделениях. Объектно-ориентированный анализ при разработке программ тоже идет от общего к частному, он начинается с декомпозиции. Аналитик в начале витает в облаках (высокие цели проекта), потом спускается до высоты птичьего полета (цели конкретизируются), опускается до уровня моря (задачи высокого уровня, направленные на решение поставленных целей), опускается в морскую пучину до рыбок и далее вниз вплоть до раковин с жемчужинами, коих тысячи (конкретные мелкие частные и неделимые задачи).
Опять же, любая работа начинается с планирования. А планировать, как это ни грустно звучит, в программной индустрии умеют считанные единицы. Более того, не могу с уверенностью сказать умею ли планировать программные проекты я сам :-)
Раз человечество выработало механизм постепенного углубления в проблему «от общего к частному», то стоит ли изменять ему при планировании программных проектов?
В КТЦ, где я имел честь служить пять лет, меня научили создавать перспективный план части (на пять лет), годовой план части, годовой план отдела, план на проект в целом, квартальный план проекта, месячный план и вплоть до недельного плана.
- Далі буде
Риски
Не подменяй управление рисками прикрывательством собственной жопы.