�ݺ�ߣ

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

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

Выводы к которым мы пришли

Ответ - построение пирамиды ответственности

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

Что делать, чтобы не «тошнило» Часть 1. Лучший отдых - смена деятельности. Работа над основным проектом не более 4 часов в день, далее работа над другими задачами (тех. поддержка старых проектов, экспертная оценка будущих проектов, работа над разными проектами), Разные проекты – разные технологии: БД (MS SQL Server, Oracle, IBM DB2), протоколы интеграции (xml, web-cервисы, smpp), прикладные интерфейсы (Win, Mac, iOS, AndroidOS) и т.д., Максимальное время работы 8 часов в день с обязательным отдыхом в выходные.

Что делать, чтобы не «тошнило» Часть 2. Работа в команде. Постоянное общение с коллегами, как только в чем-то затык, не думать часами - обсудить с коллегами, Данный затык может коснуться не только разработчика, но и весь проект в целом - найдена ошибка постановщика задачи или выявление "глубокой засады" при работе с новыми технологиями. Чем раньше будет "вскрыта" проблема, тем быстрее она решится, Формирование и использование базы знаний как по проекту, так и по отдельным находкам, Использование коллективных средств разработки, общения, обмена данными.

Что делать, чтобы не «тошнило»

Что делать, чтобы не «тошнило» Часть 5. Мотивация к работе Фиксированный оклад согласно профессиональному уровню (оценка вклада в дело, а не количество звезд и регалий), Премирование не за конкретно выполненный проект, а по итогам работы всей компании, исходя из ее прибыли . Только если вся компания сработала в прибыль, то все получат премию. Премирование по итогам квартала , а не месяца. Месяц очень короткий срок, и мало показателен. Долгосрочное сотрудничество (индексация ЗП раз в год, смена технологий, типов проектов, развитие лучшей "стороны" каждого работника).

Что делать, чтобы не «тошнило» Часть 6 . Кооперация – outsourcing Какой бы ни был бюджет и сроки проекта, а так же размер компании - быть профи во всех аспектах невозможно. В каждом проекте выделяем, то, что можем сделать сами - то, где, вы можете создать максимально добавочный продукт. Все, что в этот список не попало (например: дизайн, разработка интерфейса, верстальщик) заказываем на стороне - в другие компании, freelance.

�ݺ�ߣ

Виктор Лисицын, East Media Как учитывать время разработчиков, чтобы их не тошнило?

Recommended

More Related Content

What's hot (20)

Viewers also liked (19)

Similar to Виктор Лисицын, East Media Как учитывать время разработчиков, чтобы их не тошнило? (20)

More from Svetlana Gulyaeva (13)

Виктор Лисицын, East Media Как учитывать время разработчиков, чтобы их не тошнило?

Editor's Notes