создание сайта, разработка сайта, web design, раскрутка, раскрутка сайта, веб дизайн, web дизайн, создать сайт, интернет реклама, продвижение сайтов, изготовление сайт, web site development, создание интернет магазина, сделать сайт, дизайн сайта, веб-дизайн, web-дизайн

Статьи: веб дизайн и разработка сайтов / Менеджмент веб проектов, управление программистами / Правила Ашманова / II. Неправильный проект и его лечение Поиск
 

Вместо заключения: о чем не сказано в статье

http://www.ashmanov.com

О материальном стимулировании

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

Впрочем, могу еще заметить, что выплата разработчикам авторских процентов или проектных премий (за результат) еще никому не мешали, а вот штрафы - решительно вредны.

О специальных средствах управления проектами

Если в офшорном программировании и системной интеграции использование систем управления проектами (от MS Project до Rational Unified Process) может быть просто необходимым условием получения заказа, то в малых и коротких проектах они, на мой взгляд, необязательны, хотя и могут быть полезны. Подробное обоснование этой точки зрения - тема для отдельной статьи.

Читателю может оказаться полезной уже упоминавшаяся статья Джоэла Спольски "Painless Software Schedules" , подробно рассказывающая про эффективное использование Microsoft Excel для планирования разработки ПО и неудобство использования для тех же целей пакета для управления проектами Microsoft Project.

О стандартах качества

Применять ли стандарты качества наподобие ISO или CMM? Коротко выскажу свое мнение - тоже без развернутой аргументации. Опять-таки, для фирм, разрабатывающих ПО или информационные системы по заказу, а также для отделов разработки больших частных или государственных корпораций использование систем качества может быть не только необходимо, но и просто предписано правилами.

Однако в коротких проектах накладные расходы на поддержание системы качества могут съедать до 15-20% бюджетных средств и времени. Для короткого проекта это недопустимо.

Мне кажется, универсальные системы качества наподобие CMM и ISO являются в основном страховкой для заказчика ПО, то есть рассчитаны в основном на заказные проекты и возможность их поддержки и развития после сдачи подрядчиком.

А вот для фирм, разрабатывающих собственные программные продукты, системы качества могут оказаться вообще смертельным лекарством, потому что могут омертвить интимный процесс угадывания нужд потребителей и быстрого вывода продуктов на рынок (и подменить его работой на отдел качества). Какой смысл испытывать гордость за правильное оформление работ и возможность повторного использования кода, если продукт опоздал выйти на рынок?

Неспроста наиболее крупные и успешные разработчики ПО используют собственные, приспособленные к внутренним задачам системы качества.

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