Описание проекта

Краткое описание системы

"Корус" - система управления ресурсами и проектами для средних и больших АйТи-компаний, ведущих одновременную разработку многих проектов многими командами. Главные отличительные черты "Коруса": - ненавязчивый контроль процессов разработки, выявление проблем ещё на этапе их возникновения- помощь в их решении- выявление источника каждой проблемы.

На текущий момент есть концепция системы и проект ТЗ. 

Цель системы - упростить и удешевить процесс разработки в средних и больших компаниях.

Описание проблемы

В средних и крупных компаниях, занимающихся разработкой ПО, работающих одновременно над многочисленными проектами силами многочисленных проектных команд, особенно если какие-то ресурсы шарятся между проектами и командами, возникают следующие проблемы:

1. Некоторые системы учёта рабочего времени требуют от разработчиков вручную заполнять отчёты по часам, потраченным на проекты. Во-первых это неточно, во-вторых отвлекает разработчиков от их основной работы и раздражает их.
2. Заказчик начинает уточнять требования уже после того, как проект начали делать, и разработчикам приходится переделывать часть работы, а часть работы вообще делать заново. Лицо, ответственное за общение с заказчиком, идёт ему навстречу и принимает эти новые требования без дополнительной оплаты.
3. Если некоторые ресурсы шарятся между разными командами и разными проектами, то любая задержка разработчика на одном проекте автоматически влечёт за собой задержки на других проектах. Из-за того, что один разработчик не вышел на проект в определённый момент, начинают простаивать другие ресурсы, и убытки нарастают как снежный ком.
4. Ошибки в предварительной оценке трудозатрат по проекту ведут либо к задержкам и переработкам, либо к простою ресурсов.
5. Выполненный проект оказывается убыточным, но по прошествии значительного времени после начала его выполнения уже сложно определить, каковы причины убыточности проекта. Каждый ответственный старается переложить вину на других ответственных или на исполнителей, и определить степень вины каждого из них уже не представляется возможным.
6. Из-за некачественной работы разработчиков многие задачи приходится переделывать по несколько раз, проект не только уходит в убытки, но и опаздывает по срокам. Выявляются эти проблемы уже в тот момент, когда времени исправить проблему уже остается.
7. Ответственные за проект заранее подают в HR-департамент заявки на недостающие ресурсы, но поиск ресурсов на рынке затягивается, либо в процессе поиска стоимость ресурсов начинает превышать установленную планку, и к старту проекта ресурсов не хватает.
8. Бизнес-юниты компании думают на языке денег, технические юниты думают на языке разработки. Нет инструмента прямого перевода в конкретных цифрах с одного языка на другой, что ведёт к потерям денег и раздражению разработчиков.
9. В команду на проекте попадают люди, которые не могут сработаться друг с другом или с руководителем проекта, из-за чего проект делается с проблемами по срокам и качеству.

Всё вышеперечисленное приводит к снижению эффективности процесса разработки, недовольству и выгоранию членов команд, снижению качества продукта, и, соответственно, к финансовым потерям для компании-разработчика.

Описание системы

Предлагаемая система позволяет ненавязчиво держать под контролем все перечисленные причины потерь трудозатрат.

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

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

Описание бизнес-процесса и принципов работы системы.

В основе работы системы лежит концепция пойнтов (это не стори пойнтс!). Пойнт - базовая единица измерения ресурсов (в частности, трудозатрат), затрачиваемых на разработку проекта, привязанная к деньгам. За пойнт можно взять стоимость человекочаса работы Java-разработчика уровня Regular. Тогда, например, себестоимость часа работы Java-джуна будет составлять 0.7 пойнта, а Java-сеньора - 1.5 пойнта.

Система интегрирована с системой учёта зарплат и прочих затрат в компании, и в реальном времени "знает", в какую сумму обходится компании человекочас любого разработчика.

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

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

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

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

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

Система показывает, чей проект имеет более низкую себестоимость для компании. Также можно увидеть, насколько каждый вариант проекта обеспечен разработчиками. На основании этих данных проводится "внутренний тендер", на котором выбирается вариант архитектуры проекта и руководитель проекта.

HR-департамент компании даёт своё решение по отсутствующим в штате разработчикам - смогут или не смогут они найти их в нужный срок.

Если оценки показывают, что все необходимые ресурсы к старту проекта и в период его разработки будут в наличии, проект утверждается. Все необходимые ресурсы временно бронируются. Как только проект окончательно утверждён, бронь на ресурсы переходит в состояние постоянной.

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

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

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

На любую деятельность вне проекта также создаётся задача. Например, специалиста хотят привлечь к проведению собеседований. 

Инициатор создаёт задачу на два часа, руководитель проекта и сам специалист утверждают её, подтверждая, что специалист может отвлечься от проекта на эти два часа.

Таким образом автоматически учитывается всё время всех разработчиков.

Часы разработки, указанные в задачах и вообще в проекте, учитывают нормальный темп работы специалиста - с перерывами на перекуры и т.п.

Если какой-то специалист начинает незапланированно простаивать, он на эти часы ставит задачу "Doing nothing", а ответственные лица между собой определяют того, кто отвечает за этот простой.

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

Пульс