28.04.2023
6 самых волнующих вопросов о порядке работы на Agile
1. Как производится учет времени?
Все отработанное время логируется и учитывается в нашем багтреккере, он доступен заказчику 24 часа в сутки. Доступ предоставляется после старта работ.
2. Как мне понять, что разработчик учитывает действительно то время, которое занимался проектом, а не развлекался и устраивал перекуры?
• Все наши разработчики – ответственные специалисты с большим опытом. Мы не назначаем начинающих на коммерческие проекты. В штат стараемся брать разработчиков уровня не ниже Middle.
• Разработчики получают стабильный высокий оклад, который не зависит от выработки на коммерческих проектах. У них нет мотивации завышать выработанное время.
• Компании тоже нет смысла это делать, так как времени и сил на разборки может уйти намного больше, чем на поиски новых интересных проектов. Репутация важнее.
• На время работы над проектом разработчик или команда находятся под полным управлением заказчика, который участвует в процессе и может быть всегда в курсе текущих задач, динамики работы и т.п.
• Если возникают вопросы о продолжительности исполнения той или иной задачи, их можно задать как менеджеру проекта, так и разработчику напрямую. Мы всегда готовы дать подробные пояснения, расписать детально из чего состояли трудозатраты.
3. А если разработчик сделал что-то неправильно?
Если задача сформулирована подробно и однозначно, то и выполняется так, как описал заказчик. Если заказчик «имел в виду не то», догадаться мы об этом не можем.
Если задача сформулирована не очень подробно, перед выполнением разработчик обязан уточнять ее до тех пор, пока не будет абсолютной ясности. Все это делается в оплачиваемое заказчиком время.
В процессе работы могут появляться ошибки, требоваться эксперименты, исследование разных вариантов решений и т.п. Этот процесс называется «отладка». Она является частью цикла разработки. Эти работы необходимы для качественной разработки, поэтому время по ним фиксируется и попадает в акт.
Если разработчик не уточнил задачу, и сделал что-то другое – это неоплачиваемое время.
Бывают ситуации, когда возникают сложности, и разработчик несколько раз пытается безуспешно решить задачу с наскоку. Мы считаем, что это неправильно, и после 1-2 попыток, не приведших к результату, нужно приостановиться, посоветоваться с командой, заказчиком, поискать описание подобных проблем. Очень часто помогает даже простое переключение между проектами или пауза. Попытки, без которых можно было обойтись – не полезное для проекта время, а следовательно, и неоплачиваемое.
Заказчик, скорее всего, даже и не увидит такие логи – все неэффективное время разработчики логируют в отдельную задачу, не доступную для просмотра заказчику.
Но бывают ситуации, когда без нескольких экспериментов не обойтись. Исследовательская работа всегда согласуется с заказчиком.
4. Есть ли гарантия на вашу работу?
В классической водопадной схеме разработки стоимость гарантии рассчитывается с учетом специфики и сложности проекта, сроков гарантии и т.п. В ее стоимость закладывается большинство предполагаемых рисков. И стоимость гарантии оплачивается в любом случае, наступил гарантийный случай или нет. При этом важным моментом является экспертиза инцидента, гарантийный ли это случай. Если нет – гарантия не осуществляется. Как правило, исполнитель обязан приступить к устранению неисправности по гарантийному случаю в срок от 14 до 30 дней. Если требуется экспертиза, ее сроки тоже укладываются в 14-30 дней.
В большинстве случаев, если это не государственный контракт, такой подход не удобен и не выгоден заказчику.
Гибкая схема разработки с оплатой за часы не предполагает закладывать что-либо дополнительно в стоимость проекта, кроме выработанного времени.
Один из более гибких вариантов гарантии – согласование определенного лимита часов на исправление выявленных недочетов в месяц или год. В этом случае не нужна экспертиза. По сути, такой подход сводит гарантию к лимитированной тех поддержке. Остальное время, если оно потребуется, оплачивается либо дополнительно, либо задачи выполняются уже в следующий период.
Самый удобный вариант решения возникающих проблем – сопровождение с оплатой за часы. Технически он ничем не отличается от основной работы по разработке или доработкам проекта.
5. Передаете ли вы права на разработанное ПО?
Да. Права передаются вместе с подписанием акта приема-передачи программного обеспечения по окончании работ.
6. Я ничего не понимаю в разработке и поэтому не смогу понять сколько часов на что может понадобиться.
• По желанию заказчика мы можем предварительно оценить объем работ. Такая оценка носит приблизительный характер и показывает наиболее вероятный прогноз по трудозатратам.
• В ходе работы заказчик также может попросить оценивать каждую задачу. Это уже делается в оплачиваемое время. Такие оценки хоть и приблизительны, но более четкие. В ходе них задачи уточняются, проводится анализ самого ресурса для реализации задачи.
• Так или иначе, работая в связке с разработчиком, вы довольно быстро поймете специфику и научитесь понимать объем работ по той или иной задаче.