Блог компании Лидер·Айти

Работа над крупными проектами

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

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

После того, как проектная документация готова и оценена, начинаются работы над проектом. Мы используем в своей работе багтрекер Jira (http://www.atlassian.com/software/jira), для того чтобы разбивать задачи в ТЗ на еще более мелкие составляющие. После выполнения нескольких задач мы производим сначала внутреннюю приемку, а затем сдаем микроэтап заказчику. Таким образом клиент всегда в курсе куда и как движется его проект и может своевременно внести коррективы в ход работ.

Кроме багтрекера мы применяем репозиторий (bitbucket.org/). Он позволяет организовать групповую работу исполнителей над проектом. Слияние кода, отслеживание версий, откат назад в случае необходимости что-то исправить, сохранение исходного кода в облачном хранилище – все это позволяет нам нести ответственность за проект, находящийся в разработке и таким образом мы можем гарантировать непосредственно в договоре, что форсмажорные обстоятельства не позволят потерять важные данные.

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

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

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

Все эти факторы существенно влияют на возможность сдачи проекта в срок.

Успешная реализация проекта.

От чего зависит успешная реализация проекта? В значительной степени успех зависит от выбранного подрядчика.

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

Есть несколько советов, которые хотелось бы дать, исходя из нашего накопленного опыта и опыта наших клиентов.

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

Советуем не включать в шорт-лист частных исполнителей. Во первых работники на дому чаще всего не в состоянии выполнить крупный проект в одиночку. В крупном проекте обязательно возникают задачи по планированию, организации коммуникации между заказчиком и членами команды, да и члены команды должны быть. Команда может сделать больше чем отдельно взятый исполнитель. Так же мы часто получаем отзывы от новых клиентов, которые обращаются к нам после подобного сотрудничества — очень и очень часто крупные проекты не доводятся частными лицами до конца. Это объясняется необходимостью заниматься кроме разработки вопросами продаж своих услуг, бухгалтерскими вопросами (конечно если исполнитель регистрируется как индивидуальный предприниматель), организационными вопросами. В конечном счете на разработку остается не так много времени. Если учесть еще и частую недооценку проекта, поскольку оценивается он одним исполнителем, то риск неудачи повышается многократно.

Необходимо выбирать компании с четко отлаженными внутренними процессами по организации труда.

Исполнитель должен:

- Понимать важность логирования времени в системе учета. У вас должен быть доступ к этой системе, для возможности обсуждения задач, а так же для повышения прозрачности взаимодействия.

- Использовать в своей работе репозитории.

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

- Понимать важность разбивки проекта на этапы, а этапы на подэтапы и по каждому подэтапу организовывать итеративную разработку:

a. реализация функционала,

b. внутренняя приемка,

c. доработка функционала,

d. внутренняя приемка,

e. сдача заказчику,

f. доработка замечаний,

g. сдача.

- Иметь возможность оказания дальнейшей поддержки для проекта.

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

Ценовая политика

Проведенное нами независимое исследования рынка ИТ-разработки Москвы позволяет нам с уверенностью выставлять конкурентноспособные цены на наши услуги.

Так аналогичные компании на московском рынке, в которые мы отправляли наш запрос, предлагают рейты от 1000 до 2000 руб. в час.

Частные исполнители выставляют средние рейты от 600 до 1000 руб. в час. Читайте нашу статью почему стоит выбирать именно корпоративного исполнителя.

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

Плюсы и минусы фиксированной стоимости оплаты.

Существует два основных подхода в разработке программного обеспечения:

- Контракт с зафиксированной стоимостью оплаты (fixed price).

- Договор с почасовой оплатой труда (time & material).

Fixed price

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

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

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

Исполняя проект, по контракту с зафиксированной стоимостью, подрядчик полностью несет все риски, что отражается на конечной стоимости предложения. К оценке добавляется от 50% до 200% дополнительно заложенных трудозатрат в виде коэффициента неопределенности. Это ведет к дополнительным расходам со стороны заказчика.

Time & material

В случае применения подхода time&material оплата производится за затраченные над проектом часы. При этом нет необходимости разрабатывать детальные технические задания, поскольку разработка движется небольшими (например, недельными) итерациями. Эта схема очень хорошо сочетается с такими гибкими методологиями разработки, как Agile. Прозрачность данного подхода позволяет постоянно быть в курсе событий и непосредственно влиять на процесс разработки.

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

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

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

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

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