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

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

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

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

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

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

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

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

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

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

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

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

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