'

Спокойствие, только спокойствие

Понравилась презентация – покажи это...





Слайд 0

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


Слайд 1

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


Слайд 2

Выводы к которым мы пришли Работа разработчика - это творчество, которое не поддается количественному исчислению на единицу времени. Фиксация ЗП к потраченному времени разработчика приводит только к затягиванию сроков: чем дольше работаешь, тем больше платят (сам при этом делаешь меньше), работа во вне рабочее время (так как сроки перед клиентом прошли, а за работу по выходным платят дополнительно и по повышенной ставке). Что делать?


Слайд 3

Ответ - построение пирамиды ответственности Подбор команды на проект: 1. Руководитель проекта/постановщик задачи - посредник между продажниками(клиентом) и разработчиками, 2. Технический писатель (написание ТЗ, рабочей документации)/тестировщики. 3. Ведущий разработчик (отвечает за ядро продукта, делает основу), 4. Специалисты - профи своей части (интерфейс, протоколы интеграции, заливка данных, знание инструмента разработки). Чем меньше команда – тем лучше!


Слайд 4

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


Слайд 5

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


Слайд 6

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


Слайд 7

Что делать, чтобы не «тошнило» Часть 3. Доверие к разработчику, руководству компании. Разработчик (исполнитель) профи своего дела – не мешаем ему, главное результат, качество и сроки. Разработчик (исполнитель): не видит всей картины происходящего (вне отдела, компании), не видит внешних факторов (условия заказчика, акционеров), не владеет 100% данными по проекту. Поэтому разработчик не может объективно оценить почему было принято то или иное решение руководством. Только доверие к людям и вера в компанию приводит к успеху всей команды!


Слайд 8

Что делать, чтобы не «тошнило» Часть 4. Работа только в радость и удовольствие Если разработчик "не хочет" работать над данным проектом, то лучше не брать его в команду, Если "не хочет" работать во всех проектах компании, то лучше расстаться. Работа должна приносить прежде всего удовольствие!


Слайд 9

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


Слайд 10

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


Слайд 11

The End! И самое главное при этом испытывать спокойствие, только спокойствие. Ваши вопросы? Виктор Лисицын, vlisicyn@east-media.ru http://twitter.com/EastMediaLtd www.east-media.ru


×

HTML:





Ссылка: