Управление проектами - статьи

         

Общие рекомендации по организации процесса разработки


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

  • Постарайтесь, насколько возможно, разделить территориально разработчиков ПО и других специалистов

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

  • Запретите кому бы то ни было, кроме менеджера проекта, непосредственно давать указания разработчикам

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

  • Выделите либо человека, либо время на обсуждение задач

    Практика показывает, что задачи по сопровождению-разработке ПО возникают постоянно в течение дня, обстоятельства почти всегда требуют немедленного выяснения. Если вы имеете двух разработчиков, пусть они по очереди общаются с представителями заказчика, если у вас есть специально выделенный для этого менеджер - пусть общается он. Проблема здесь в том, что административные функции (выяснение обстоятельств проблем, степени их важности, взаимодействие с заинтересованными лицами) требуют оперативности, в то время как техническая реализация запросов, наоборот, наиболее эффективна при возможности сосредоточиться на проблеме на длительное время.
    Постоянное отвлечение внимания разработчика, кроме снижения эффективности работы, имеет еще один отрицательный результат: трудность адекватной оценки фактических трудозатрат. Между тем, без фиксирования фактических затрат, разработчик теряет навык делать правильные оценки.

  • Выделите для разработчиков отдельный телефонный номер

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

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

    В изменяющемся мире бизнеса, например, в телекоммуникационном бизнесе, число задач, связанных с поддержкой существующих систем остается примерно постоянным. Небольшие изменения в существующем ПО требуются регулярно. В процессе разработки нового ПО число систем, которые необходимо сопровождать, растет. Что получается? Суммарное число задач растет со временем. Если разработчик говорит, что он перестает справляться с объемом задач, скорее всего это так. Возьмите еще одного человека, либо закажите разработку и сопровождение части ПО другим организациям.
  • Обеспечьте для разработчиков обучение и обмен опытом

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

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

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


    Содержание раздела







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