Командная работа и скрытые сообщения
Бывают системы автоматизации, которые автоматизируют имеющиеся в компании процессы, не внося в них существенных изменений. Такую систему кажется просто внедрить, но эффект от ее внедрения сложно измерим и не всегда понятно, а был ли смысл. И самое главное - а можно ли было сделать лучше? т.е. не только автоматизировать то, что есть, но и улучшить сами процессы?
Я уже писал, что qTrack создает "единое пространство для заказчика и исполнителя", но что это меняет в самом процессе создания проектов и как получить от этого прямую выгоду?
На прибыль проектной компании большое влияние оказывает себестоимость проектов, причем чем как правило, чем больше проектов в работе, тем выше себестоимость каждого отдельного проекта - из-за роста административных издержек и снижения контроля руководителей.
т.е. получается, что расходы начинают опережать доходы, что вынуждает повышать цену и терять клиентов - получается замкнутый круг: увеличивая число проектов растет доход (оборот), но падает рентабельность и в итоге прибыль остается на прежнем уровне или даже падает. Из-за управленческих и кадровых проблем падает качество и компания начинает терять клиентов.
Отсюда мораль: нужно повышать эффективность работы и рентабельность проектов.
Может ли в этом помочь система автоматизации управления проектами - безусловно да, вопрос только в том, на сколько. Если внедрять систему управления проектами не меняя имеющиеся процессы, вряд ли можно получить прирост эффективности более 5-10%, а при неудачном выборе системы возможно даже снижение эффективности - например, если люди будут тратить слишком много времени на заполнение ненужных форм и т.д.
Значит, надо не только внедрять систему управления проектами, но и менять бизнес процессы. Но как? Экспериментировать на собственной компании может быть слишком дорого.
Есть простое решение - взять систему автоматизации, которая подразумевает определенные бизнес-процессы разработки проекта. Например, в it-проектах есть концепция гибкого подхода (agile) и множество систем автоматизации, поддерживающих такой подход. Лично мне нравится agile и мы используем его принципы в своей работе (с определенной степенью модификации ес-но), но для заказной разработки с фиксированной стоимостью, сроком и ТЗ - agile не учитывает важную составляющую - отношения с заказчиком. А как показывает опыт, влияние заказчика на рентабельность очень велико.
Наша концепция - использовать гибкий подход в негибких условия контракта с формализованным корпоратавным заказчиком. т.е. обеспечить контролируемое и ограниченное вовлечение заказчика в процесс разработки проекта и получить от этого максимальную пользу.
Для этого с одной стороны нужно спрямить отношения конкретных людей из команды заказчика и людей из команды разработки, с другой стороны, нельзя пускать процесс на самотек и позволить заказчику управлять нашими специалистами.
Если переходить к системе автоматизации, то она должна одновременно пускать заказчика к решению и обсуждению задач, и при это ограничивать его возможности. Рассмотрим простой пример: в проекте по созданию сайта, нам бы хотелось, чтобы разработчик мог напрямую получить список багов от заказчика и даже сам бы мог задать уточняющие вопросы и отписаться о выполнении, но при этом мы хотим чтобы под видом ошибок не вносились новые требования, чтобы перед ответом заказчику было проведено тестирование (несколько циклов "менеджер-разработчик", да и вообще быть в курсе происходящего.
т.е. нужно чтобы команда разработчиков проекта и заказчик пользовались одной и той же системой управления. Более того, чтобы один вопрос (например, реализация одной бизнес-функции) решался в одном месте (задаче, тикете) и заказчиком и командой исполнителя. Но при этом у команды исполнителя должна быть возможность обсудить некоторые моменты так, чтобы заказчик не видел этого обсуждения.
Для этого и нужны внутренние (скрытые от других команд) сообщения в рамках тикета.
Этот несложный технический инструмент позволяет координально изменить и оптимизировать бизнес процессы выполнения проекта. Настолько, что эффект от внедрения такого подхода может сэкономить реальные деньги.
Дополнительные бонусы, получаемые от внедрения единого пространства задач с использованием внутренних обсуждений:
- возможность сдавать работы по частям (обеспечив итерационность разработки)
- возможность вести проект при временном отсутствии менеджера (отпуск, болезнь)
- возможность оперативно реагировать на срочные обращения от заказчика даже когда менеджер занят (например, другим проектом)
- возможность сменить менеджера и даже команду проекта (например, перевести их на более важный проект) без существенных проблем (все знания по проекту и история разработки и сдачи каждой задачи зафиксированы)
Таким образом, принимая решение о выборе системы управления проектами, можно задуматься не только об автоматизации имеющихся процессов, но и о переходе к качественно новому подходу к бизнес-процессам.
ссылки по теме: qtrack.ru qcrm.ru
Я уже писал, что qTrack создает "единое пространство для заказчика и исполнителя", но что это меняет в самом процессе создания проектов и как получить от этого прямую выгоду?
На прибыль проектной компании большое влияние оказывает себестоимость проектов, причем чем как правило, чем больше проектов в работе, тем выше себестоимость каждого отдельного проекта - из-за роста административных издержек и снижения контроля руководителей.
т.е. получается, что расходы начинают опережать доходы, что вынуждает повышать цену и терять клиентов - получается замкнутый круг: увеличивая число проектов растет доход (оборот), но падает рентабельность и в итоге прибыль остается на прежнем уровне или даже падает. Из-за управленческих и кадровых проблем падает качество и компания начинает терять клиентов.
Отсюда мораль: нужно повышать эффективность работы и рентабельность проектов.
Может ли в этом помочь система автоматизации управления проектами - безусловно да, вопрос только в том, на сколько. Если внедрять систему управления проектами не меняя имеющиеся процессы, вряд ли можно получить прирост эффективности более 5-10%, а при неудачном выборе системы возможно даже снижение эффективности - например, если люди будут тратить слишком много времени на заполнение ненужных форм и т.д.
Значит, надо не только внедрять систему управления проектами, но и менять бизнес процессы. Но как? Экспериментировать на собственной компании может быть слишком дорого.
Есть простое решение - взять систему автоматизации, которая подразумевает определенные бизнес-процессы разработки проекта. Например, в it-проектах есть концепция гибкого подхода (agile) и множество систем автоматизации, поддерживающих такой подход. Лично мне нравится agile и мы используем его принципы в своей работе (с определенной степенью модификации ес-но), но для заказной разработки с фиксированной стоимостью, сроком и ТЗ - agile не учитывает важную составляющую - отношения с заказчиком. А как показывает опыт, влияние заказчика на рентабельность очень велико.
Наша концепция - использовать гибкий подход в негибких условия контракта с формализованным корпоратавным заказчиком. т.е. обеспечить контролируемое и ограниченное вовлечение заказчика в процесс разработки проекта и получить от этого максимальную пользу.
Для этого с одной стороны нужно спрямить отношения конкретных людей из команды заказчика и людей из команды разработки, с другой стороны, нельзя пускать процесс на самотек и позволить заказчику управлять нашими специалистами.
Если переходить к системе автоматизации, то она должна одновременно пускать заказчика к решению и обсуждению задач, и при это ограничивать его возможности. Рассмотрим простой пример: в проекте по созданию сайта, нам бы хотелось, чтобы разработчик мог напрямую получить список багов от заказчика и даже сам бы мог задать уточняющие вопросы и отписаться о выполнении, но при этом мы хотим чтобы под видом ошибок не вносились новые требования, чтобы перед ответом заказчику было проведено тестирование (несколько циклов "менеджер-разработчик", да и вообще быть в курсе происходящего.
т.е. нужно чтобы команда разработчиков проекта и заказчик пользовались одной и той же системой управления. Более того, чтобы один вопрос (например, реализация одной бизнес-функции) решался в одном месте (задаче, тикете) и заказчиком и командой исполнителя. Но при этом у команды исполнителя должна быть возможность обсудить некоторые моменты так, чтобы заказчик не видел этого обсуждения.
Для этого и нужны внутренние (скрытые от других команд) сообщения в рамках тикета.
Этот несложный технический инструмент позволяет координально изменить и оптимизировать бизнес процессы выполнения проекта. Настолько, что эффект от внедрения такого подхода может сэкономить реальные деньги.
Дополнительные бонусы, получаемые от внедрения единого пространства задач с использованием внутренних обсуждений:
- возможность сдавать работы по частям (обеспечив итерационность разработки)
- возможность вести проект при временном отсутствии менеджера (отпуск, болезнь)
- возможность оперативно реагировать на срочные обращения от заказчика даже когда менеджер занят (например, другим проектом)
- возможность сменить менеджера и даже команду проекта (например, перевести их на более важный проект) без существенных проблем (все знания по проекту и история разработки и сдачи каждой задачи зафиксированы)
Таким образом, принимая решение о выборе системы управления проектами, можно задуматься не только об автоматизации имеющихся процессов, но и о переходе к качественно новому подходу к бизнес-процессам.
ссылки по теме: qtrack.ru qcrm.ru