Что делать, если вы сотрудничаете с компанией-разработчиком и не довольны совместной работой? Потратили деньги, время и нервы на создание IT-продукта, но не получили ожидаемых результатов. Перечислю красные флаги, на которые стоит обратить внимание.
1. Регулярно нарушаются сроки разработки
В реальности дедлайны срывают почти все, и нарушение сроков подрядчиком – не повод сразу расторгать договор. Но нужно понять, по каким причинам, и как исполнитель работает с этим. Если менеджеры заранее вас об этом предупреждают, признают вину и предлагают решение проблемы, беспокоиться пока не о чем. Но бывает, что команда начинает игнорировать вас в рабочих чатах, долго отвечает, находит отговорки или несправедливо обвиняет ваших специалистов. Это повод задуматься: доверять ли дальше подрядчику, который выбирает такую стратегию поведения и нарушает правила исполнения контракта.
Возможность заранее предупредить о сдвигающихся сроках сдачи работы есть почти всегда, если процессы внутри команды выстроены правильно. Поэтому смело требуйте ответственности подрядчиков и гарантий.
Что делать в этой ситуации
- Узнайте причину просроченного дедлайна. Созвонитесь с подрядчиком и выясните, почему его команда не справилась в сроки. Попросите их в следующий раз заранее предупреждать о перенесенном тайминге и быть на связи для обсуждения дальнейших действий.
- Предложите включить в договор дополнительные пункты про дедлайны и штрафы за их нарушения. Такие санкции помогут исполнителям серьезнее относиться к своим обязанностям.
- Возьмите процесс контроля в свои руки. Если сроки нарушаются регулярно, чаще отправляйте подрядчикам в общие чаты напоминания о дедлайнах, обязанностях и договоренностях о выполнении работ и интересуйтесь, на каком этапе находится проект. Сам факт того, что приходится так часто отправлять претензии подрядчику, уже говорит о проблемах. Но ваша инициатива поможет получить хоть какой-то результат, пока, например, ищете новую команду.
2. Бюджет постоянно растет
Стоимость проекта со временем может измениться по трем основным причинам:
- Если продукт популярен среди пользователей и требует развития новых направлений и функций.
- Заказчик в процессе разработки уточняет или меняет требования к подрядчику, из-за чего увеличивается бюджет. И это нормально.
- Исполнитель по ошибке или намеренно озвучил нереалистичный бюджет. Например, специально предложил низкую стоимость, чтобы обойти конкурентов. Или неправильно оценил объем работы на этапе аналитики. Еще вариант: исполнитель просто хочет больше заработать на вас. В этих случаях стоит задуматься о финальном расчете с подрядчиком.
Что делать в этой ситуации
- Когда разработчики повышают оплату за услуги, просите объяснить это решение. Если это действительно обоснованно и подрядчик добросовестный, вы наверняка услышите логичные аргументы. А расплывчатые формулировки и слабая аргументация – повод насторожиться.
- Попросите независимых программистов оценить стоимость задачи перед итоговым согласованием подрядчика. Если цифры примерно совпадают, беспокоиться не о чем.
- Если обоснованных аргументов нет, а другие разработчики оценивают работы намного дешевле, есть повод подумать о смене команды, пока не понесли серьезные временные и финансовые потери.
3. С вами работают по остаточному принципу
Есть случаи, когда во время этапа продаж и согласования работ исполнитель направляет все внимание на заказчика и показывает хороший сервис. Но как только договор подписан, подрядчик начинает терять к вам интерес, все дольше отвечает в чатах, редко предлагает идеи по улучшению. Вы начинаете чувствовать, что у команды есть более приоритетные клиенты, и вы перестали входить в их число.
Что делать в этой ситуации
Напомните подрядчику о себе: скажите, что вам хотелось бы быстрее получать ответы в чате и отчеты о проделанной работе. Или чаще созваниваться и обсуждать проект. Возможно, команда действительно расслабилась и устала после активных обсуждений проекта, но после напоминания снова войдет в тонус. Если этого долго не происходит, есть большая вероятность, что компания действительно не считает вас приоритетным заказчиком.
4. Команда долго не может показать промежуточное демо
Еще одна частая проблема – подрядчик не может презентовать то, что сделано на настоящий момент. Кормит завтраками или присылает только скриншоты проекта. Обычно это означает, что разработка либо вообще не двигается, либо движется значительно медленнее утвержденного графика. У команды могут быть проблемы с ресурсами: разработчики заняты, заболели или уволились. Или не рассчитали силы и долго разбираются с проектом.
Это может привести к переносу сроков или низкому качеству кода с невозможностью его дальнейшей поддержки. А если демо проходит редко, на финальной презентации вы можете получить не совсем то, что планировали, так как не видели промежуточных результатов.
Что делать в этой ситуации
- Узнайте у команды причину, по которой откладывается демо. Если product-менеджер не дает ясных причин и уходит от ответа, попробуйте сослаться на официальные юридические договоренности. В случае, когда вам самим приходится регулярно напоминать о презентации, но конкретный срок так и не обозначают, обдумайте, стоит ли вам продолжать сотрудничество.
- Если вас не устраивает периодичность презентаций, согласуйте с подрядчиком график. В идеале проводить демо после каждого спринта, чтобы вы могли заранее протестировать продукт, внести изменения и обсудить идеи по развитию. Так вырастет вероятность того, что вы будете довольны результатом.
5. Product-менеджер отказывается позвать на звонок разработчиков
Если на встречи к вам приходит кто угодно, но не программисты, стоит подумать о причине такого решения. Есть вероятность, что команда отдала ваш проект на субподряд, не предупредив вас. Или всю работу делает другой разработчик, например, вместо заявленного сеньора код пишет джун. Какие последствия могут быть для проекта? Если это субподряд, могут часто срываться сроки из-за нескольких звеньев коммуникации. Или возникнут проблемы с качеством кода, если его писал неопытный разработчик.
Что делать в этой ситуации
Если вам важно, кто именно работает над проектом и пишет код, запросите у product-менеджера встречу с разработчиками и информацию об их квалификации. Добросовестный подрядчик поймет ваш запрос и организует встречу, так как ему нечего скрывать. Недобросовестный, скорее всего, найдет причины, чтобы этого не делать.
Как не допустить проблемных ситуаций с IT-подрядчиком в будущем
Даже если однажды вам попалась непрофессиональная компания-разработчик, это не значит, что на рынке нет хороших подрядчиков. Просто учтите предыдущие уроки и поменяйте подход к выбору и работе с командами на аутсорсе.
- Внимательно составляйте контракт, прописывайте требования, штрафные санкции и условия привлечения исполнителей к ответственности. И помните, что вы с подрядчиком – деловые партнеры, даже если давно знаете этих людей. Важно скрупулезно выдерживать бухгалтерскую и юридическую линию, делать акты, подтверждать работу отчетами и так далее.
- Заранее договоритесь с подрядчиком о способах, графике и частоте коммуникации. В каких мессенджерах будете общаться и презентовать демо, как часто хотите видеть отчеты и в какие сроки получать ответы на свои вопросы. Бывает, что для одной стороны ждать ответа 2 часа – это ненадлежащее исполнение обязательств, а для другой – обычный ритм общения из-за большой загрузки. Проговорите эти моменты на этапе подписания договора.
- Помимо генерального подрядчика держите при себе контакты запасных подрядчиков. Такая подстраховка поможет проверить реалистичность озвученных бюджетов и сроков, и снизит риски, если выбранный подрядчик все-таки подведет.
Также читайте:
Когда читаешь дедлайн, тайминг, демо (??!!) – понимаешь, это все, сливай воду. Что значит, иметь в запасе другого разработчика – деньги на ветер, и чем другой, будет лучше первого. Совет один, не берите целостную систему, с большой вероятностью вам придется перестраивать бизнес или проводить многочисленные доработки, что снизит эффективность работы ПО в разы. Поручайте разработку ПО для ваших отдельных небольших функций. Вы почувствуйте уровень разработчика и ваше взаимопонимание. После этого можно расширять задачи.
Про график платежей в статье ничего не сказано. Сытый лев не охотится.
К статье очень много вопросов. Какую приблуду делают - серийный, единичный? Что за команда? Смущают, например, такие места: "Если на встречи к вам приходит кто угодно, но не программисты, стоит подумать о причине такого решения. Есть вероятность, что команда отдала ваш проект на субподряд, не предупредив вас". Если программисты будут ходить на встречу с заказчиком, то проект точно никогда не завершится.
Коллеги правы - а где слова про график платежей? А этапы сдачи и испытаний? Почему заказчик должен тестировать продукт?
Я так понимаю, что речь идёт о какой-то индивидуальной разработке с не очень ясными целями, потому что упор делается на демо-версиях. Это так?
Здравствуйте, в первом пункте упоминал штрафные санкции и необходимость внимательно выдерживать бухгалтерскую и юридическую линию. Это, разумеется, подразумевает и наличие графика платежей. Видимо, не вполне очевидно выразился.
Здравствуйте, Леонид!
Зачем сливать воду? Это стандартная лексика в IT.
Иметь в запасе другого разработчика = иметь его контакты под рукой для подстраховки, не более того. О деньгах здесь речи нет.
Согласен, сотрудничество с новым подрядчиком стоит начинать с небольших задач, чтобы сразу оценить комфортность и качество работы. Именно так у нас отношения со многими заказчиками переросли в комплексное многолетнее сотрудничество.
Здравствуйте, Анатолий.
В статье идет речь о заказной разработке любых цифровых продуктов — приложений, сайтов, интернет-магазинов, сложных систем. В проектную команду входят разработчики, аналитик, дизайнер(ы), тестировщик(и), менеджер.
Демо — это системная практика, обычно проводится, чтобы продемонстрировать заказчику проделанную работу (как раз по окончании каждого этапа, о которых вы спрашиваете), тестовую версию продукта, новую функциональность и т.д. Это необходимо, чтобы получить обратную связь от заказчика и правки для следующей итерации продукта.
По поводу встреч с программистами, стоит обратить внимание на абзац: "Если вам важно, кто именно работает над проектом и пишет код, запросите у product-менеджера встречу с разработчиками и информацию об их квалификации." Организовать встречу с тех.специалистом по просьбе заказчика — обычное дело, не на регулярной основе как правило.
Благодарю, Владислав, за ответ!
Да, у вас индивидуальная разработка. Ваши проблемы ох как понимаю. Вот только информацию о разработчиках и их квалификации обычно заранее спрашивают. Во время начатой разработки это, на мой взгляд, уже не имеет смысла.
И смею сделать предположение, что тз не очень тщательно проработано. Но это не упрёк, просто мнение. Вы правы - приходится делать демо на каждом этапе и корректировать задачу.