Чек-лист вопросов подрядчику перед разработкой ПО для бизнеса
Кажется, вы нашли ту самую команду для разработки вашего продукта: у них подходящий стек технологий, убедительные кейсы и вменяемые сроки. Осталось подписать договор – и проект стартует. Но здесь кроется ловушка, в которую попадают даже опытные заказчики ПО для бизнеса.
Мы все фокусируемся на функциональности, технологиях и бюджете. Скрупулезно изучаем техническое задание, словно это карта сокровищ. Однако самая частая причина провала ИТ-проектов лежит не в области кода, а в области человеческих отношений, процессов и невысказанных ожиданий.
Срыв сроков, уход ключевых разработчиков с проекта, внезапные доплаты за «неучтенные работы», код, который невозможно передать другой команде, – все это корни проблемы. И растут они из почвы под названием «неправильно выстроенное взаимодействие». Вы покупаете не просто линии кода. Вы покупаете партнерство, предсказуемость и чужой управленческий опыт.
Поэтому, прежде чем поставить подпись, стоит задать последний, самый важный набор вопросов. Не про технологический стек, а про культуру работы компании и конкретные действия в момент кризиса. Ответы на них покажут, с кем вы на самом деле собираетесь пройти долгий и сложный путь создания цифрового продукта. Давайте начнем этот непростой, но необходимый разговор.
Вопросы о процессах и управлении проектом
Технические навыки команды – это двигатель, а процессы – это навигационная система, без которой даже самый мощный двигатель унесет вас в неизвестном направлении.
В этом блоке мы спросим не о том, может ли команда что-то сделать, а о том, как именно она это делает, когда сталкивается с реальностью меняющихся требований, дедлайнов и технических сложностей.
Вопрос 1: «Как вы фиксируете решения, которые рождаются в ходе работы?»
В ходе живой дискуссии с аналитиком и разработчиком рождается идея, которая упрощает будущую функцию для пользователя и экономит ваше время. Все согласны, решение кажется гениальным, его начинают внедрять. Но через месяц вы с удивлением видите в тестовой среде совсем не то, что ожидали.
В чем подвох? Устные договоренности в чатах и на звонках – зыбучий песок, на котором нельзя строить проект. Зрелый подрядчик понимает, что любое значимое изменение должно быть зафиксировано. Спросите: «Можете показать пример, как выглядит запись такого решения?».
Хороший ответ будет звучать конкретно: «Мы ведем протокол решений в виде таблицы или в Confluence. В него сразу после встречи вносится: суть решения, причина, кто принял и дата. Ссылка на эту запись прикрепляется к задаче в нашем трекере (Jira, YouTrack)». Это говорит о дисциплине и уважении к договоренностям как к активам проекта.
Вопрос 2: «Что происходит, когда команда понимает, что не успевает к контрольной точке?»
В любом живом проекте случаются непредвиденные сложности: библиотека оказывается нестабильной, интеграция с внешним сервисом требует в три раза больше времени, ключевой сотрудник заболел. Реакция на эту ситуацию – лакмусовая бумажка зрелости подрядчика.
Насторожитесь, если в ответ вы слышите бодрое: «Не волнуйтесь, наши ребята герои, они будут работать по ночам и выходным». Это путь к выгоранию, низкому качеству и скрытому недовольству. Это культура героизма, а не управления.
Пример сильного ответа: «Согласно нашему процессу, как только тимлид или PM видят угрозу срыва дедлайна, мы проводим анализ: в чем коренная причина? Затем мы готовим варианты решений на выбор: можем ли мы упростить функционал в этой итерации, чтобы уложиться в срок? Или нужно сдвинуть дедлайн, но сохранить объем? Или добавить ресурсы, что повлечет корректировку бюджета?». Такой подход превращает кризис в совместную рабочую задачу.
Вопрос 3: «Как в проекте предусмотрена работа с техническим долгом?»
Представьте, что вы строите дом и решаете сэкономить на фундаменте, чтобы быстрее въехать. Год-два все хорошо, а потом начинают расходиться стены. В разработке то же самое. Технический долг – это те самые «костыли» и упрощения в коде, которые позволяют быстро выпустить фичу, но делают систему хрупкой, негибкой и дорогой в поддержке в будущем.
Если подрядчик говорит: «Мы пишем чистый код, долга не будет» – он либо наивен, либо нечестен. Долг возникает всегда: из-за срочных правок, устаревания технологий, смены приоритетов.
Правильный вопрос не «Будет ли долг?», а «Как вы им управляете?». Хороший ответ может быть таким: «Мы закладываем время на рефакторинг (улучшение кода без изменения функциональности) в каждый спринт – обычно 10-20% от времени команды. Кроме того, мы ведем реестр выявленных «долговых обязательств», оцениваем их критичность и обсуждаем плановые «спринты по обслуживанию», где мы фокусируемся только на качестве системы».
Вопросы о коммуникации
Можно выбрать самую продвинутую методологию, нанять блестящих архитекторов и утвердить идеальный план. Но если ежедневное взаимодействие построено на песке, проект неизбежно начнет трещать по швам. Прозрачность – это практический инструмент, который позволяет вам, заказчику, спать спокойно. Не потому что все идет идеально, а потому что вы всегда в курсе, как обстоят дела на самом деле.
В этом блоке вопросов мы спрашиваем о конкретных механизмах, которые превращают абстрактное «мы на связи» в понятный и работающий режим диалога.
Вопрос 4: «Кто наша единая точка контакт с вашей стороны, и что будет, если он уйдёт?»
Представьте, что у вас десять специалистов от подрядчика: аналитик, разработчик, тестировщик. И с каждым из них по отдельности можно решить узкий вопрос. Но что делать, когда нужен общий курс, согласование приоритетов или срочное решение проблемы, затрагивающее всех?
Спросите прямо: «Кто является нашей единой точкой контакта и конечным ответственным за коммуникацию с вашей стороны?»
Сильный ответ будет конкретным: «Вашим постоянным капитаном будет Алексей, наш проектный менеджер. Он сводит воедино все потоки информации от команды, готовит отчеты и является человеком, к которому вы приходите с любым вопросом. Он отвечает на письма и сообщения в течение 4 рабочих часов в течение дня».
Но есть ещё один вопрос: «А что происходит, когда Алексей в отпуске, на больничном или на конференции?». Если в ответ пауза или «как-нибудь свяжетесь с командой», это красный флаг.
Правильный ответ: «У Алексея есть официальный заместитель – Ольга, которая в курсе всех деталей проекта. В его отсутствие автоматически все коммуникации переходят к ней, и мы заранее вас с ней познакомим. Кроме того, все ключевые решения и статусы всегда фиксируются в наших системах, так что контекст не теряется».
Вопрос 5: «Как именно мы будем видеть прогресс?»
Фраза «мы будем присылать вам отчеты» ничего не значит. Задайте вопрос так: «Какие конкретные отчеты или дашборды мы будем получать и с какой регулярностью? Можем ли мы повлиять на их формат? Например, нам критично видеть не количество выполненных задач, а прогресс по ключевым пользовательским сценариям».
Хороший подрядчик отреагирует с интересом: «Стандартно мы раз в неделю проводим демо-сессию, где показываем рабочий продукт, и раз в спринт присылаем отчет по нашим согласованным метрикам. Мы можем добавить туда конкретные KPI вашего бизнеса, завязанные на релиз, или график покрытия автоматическими тестами, если это для вас важно. Давайте обсудим, какие 3-4 цифры для вас самые главные».
Это показывает, что подрядчик думает не об отчете ради отчета, а о том, чтобы вы владели ситуацией.
Вопрос 6: «Как мои эксперты будут общаться с вашими разработчиками?»
Это самый болезненный момент во многих проектах. Ваш специалист отдела продаж, который знает все нюансы работы с клиентом, но его время – золото. А с другой стороны – разработчик, который в деталях должен понять логику, чтобы воплотить ее в код.
Если их связывает только длинная цепочка, то смысл теряется на полпути. Получается игра в испорченный телефон. Спросите: «Как организовано прямое, но управляемое взаимодействие между моими предметными экспертами (например, главным бухгалтером или руководителем отдела логистики) и вашими разработчиками или аналитиками?»
Правильный ответ описывает безопасный канал, а не хаос: «Мы против того, чтобы разработчики писали вашим экспертам в личные мессенджеры в любое время. Это нарушает их работу. Вместо этого мы практикуем запланированные рабочие сессии. Все вопросы к эксперту копятся в течение недели в специальном документе, чтобы встречи были максимально эффективными».
Такой подход показывает уважение к времени и экспертизе обеих сторон и убивает недопонимание.
Вопросы о команде
Этот блок – самый личный и самый важный. Он не о технологиях, а о том, что движет людьми, которые будут воплощать вашу идею в код. Мы задаем вопросы, которые помогают понять, с кем именно вы вступаете в долгое путешествие и насколько им самим интересен ваш маршрут.
Вопрос 7: «Насколько постоянна команда?»
Страшный сон заказчика: после трех месяцев погружения в ваш бизнес-домен, когда разработчик уже начинает мыслить категориями вашей логистики и финансов, он не выходит на связь.
Вопрос о стабильности команды – это не праздное любопытство. Это оценка фундаментального риска. Спросите прямо: «Какова текучесть кадров в вашей компании и в командах, аналогичных нашей? Что вы делаете, чтобы ключевые люди оставались в проекте от начала и до конца?»
Настораживающий ответ: «Мы гарантируем, что команда будет, но конкретных людей гарантировать не можем. У нас сильный пул, мы быстро найдем замену».
Сильный, честный ответ звучит иначе: «Мы отслеживаем этот показатель, и в среднем по компании текучесть ниже рыночной – около 10-12% в год. Для долгосрочных проектов мы формируем ядро команды из сотрудников, которые уже давно с нами и не планируют уходить. Если же непредвиденная замена все же требуется, мы закладываем в план время на адаптацию нового человека и организуем полную передачу знаний от уходящего специалиста».
Вопрос 8: «Что мотивирует вашу команду сделать наш проект не просто хорошо, а блестяще?»
Ваш вопрос должен раскрыть, насколько команда вовлечена в общий успех. Спросите: «Какие KPI или цели есть у команды на нашем проекте? Как они связаны с качеством продукта или бизнес-результатом для нас?»
Плохой признак, если ответ сводится к: «Их KPI – выполнять план спринта и закрывать задачи в Jira».
Что вы хотите услышать: «Мы стараемся уходить от оценки просто по часам. На уровне команды мы можем закладывать такие метрики, как процент автоматизированных тестов, снижение количества критических багов в продакшене после релиза, скорость загрузки ключевых страниц. Но главное – мы вовлекаем команду в понимание вашей бизнес-цели».
Вопросы о рисках
Самый надежный партнер – тот, кто не боится обсудить с вами сценарий, в котором ваше сотрудничество закончится. Потому что он уверен в качестве своей работы и строит отношения на честности, а не на зависимости.
Этот блок – про реализм и управление активами. Ваш код, ваши данные и непрерывность вашего бизнеса – это ваша собственность. Хороший подрядчик не просто создает продукт, он создает его так, чтобы вы им свободно владели.
Вопрос 9: «Глядя на наш проект со стороны, какие три главных риска вы уже сейчас видите?»
Подрядчик в ответ на этот вопрос пожимает плечами и говорит: «Рисков нет, все под контролем, у нас отработанный процесс»? Либо не хочет думать, либо намеренно скрывает очевидное. Нет проекта без рисков, а умение их заранее идентифицировать и говорить о них открыто – ключевой навык профессионала.
Сильный ответ будет структурированным и конкретным: «Исходя из краткого брифа, мы видим несколько потенциальных зон повышенного внимания…».
Такой ответ превращает абстрактную угрозу в совместную рабочую задачу и показывает, что подрядчик мыслит как ваш партнер, а не как сторонний исполнитель.
Вопрос 10: «Как в вашем договоре прописан процесс передачи всех материалов, если мы решим сменить подрядчика?»
Этот вопрос – тест на искусственную зависимость от поставщика. Незрелая компания может сознательно или неосознанно создавать проекты, которые невозможно забрать: писать код без документации, использовать уникальные проприетарные инструменты, хранить все доступы у себя.
Ваша цель – понять, считает ли подрядчик код и знания вашей собственностью. Сформулируйте вопрос твердо: «Предположим, после года сотрудничества мы решим перевести проект на внутреннюю поддержку или к другой команде. Опишите пошагово, как будет выглядеть процесс передачи. Что конкретно мы получим на выходе и за какой срок?»
Честный и профессиональный ответ будет звучать обнадеживающе: «Это стандартный пункт нашего договора. Мы гарантируем передачу всего, что создано в рамках проекта, в течение 30 дней после окончания сотрудничества. Вам будет предоставлен:
Вопрос 11: «Есть ли у вашей компании план обеспечения непрерывности бизнеса применительно к нашим проектам?»
Мир непредсказуем: компания-подрядчик может столкнуться с финансовыми трудностями, форс-мажором или просто внезапным закрытием. Что произойдет с вашим проектом, который находится на их серверах, в их системах контроля версий и в головах их сотрудников?
Этот вопрос отделяет компании-однодневки или хрупкие студии от серьезных игроков. Вы спрашиваете не о гарантиях, а о системе. Ожидаемый ответ от зрелой компании: «Да, такой план существует, и мы готовы обсудить его ключевые положения, касающиеся клиентских проектов. В двух словах:
- Код и данные: все репозитории и данные клиентов хранятся не на локальных машинах, а в защищенных облачных сервисах. В случае чего вы сможете просто забрать свои активы оттуда.
- Доступы: мы практикуем принцип наименьших привилегий и ведем журнал выдачи доступов. В договоре мы можем прописать, что вы получаете мастер-доступ к облачным сервисам проекта, а мы работаем через вложенные аккаунты.
Вопросы о ценностях и культуре
Ответы здесь редко бывают правильными или неправильными, но должны быть искренними. Здесь мы спрашиваем не о том, что делает компания, а о том, во что она верит.
Вопрос 12: «Можете рассказать о случае, когда ваши интересы как бизнеса вступали в конфликт с интересами клиента? Как вы поступили?»
Худший ответ – отрицание: «У нас никогда не было такого, наши интересы всегда совпадают с интересами клиентов». Это неправда, хороший ответ – конкретная история с рефлексией.
Например: «Был проект, где на этапе тестирования выяснилось, что выбранная нами архитектурная библиотека начинает вызывать проблемы с производительностью при высокой нагрузке. У нас был выбор: закрыть глаза, оптимизировать костылями и сдать проект вовремя, либо признать ошибку и предложить клиенту дорогостоящий и сдвигающий дедлайн рефакторинг на другой технологии. Мы несколько компенсационных вариантов, проект сдали на месяц позже, зато он до сих пор работает, а тот клиент стал нашим амбассадором и привел нам еще три проекта».
Вопрос 13: «Что для вас будет означать «успех» нашего проекта через полгода после его запуска?»
Ответ, на который стоит обратить внимание: «Для нас успех делится на две части:
- Проект сдан, команда рада, вы довольны процессом, все артефакты переданы.
- То, как система помогла вам. Например, что время обработки заявки сократилось на 30%, что отдел продаж начал заключать на 15% больше сделок благодаря новой CRM, или что ваш клиенты стали меньше жаловаться на личный кабинет».
Такой ответ означает, что подрядчик хочет разделить с вами не только трудности разработки, но и радость от победы.
Вопрос 14: «Расскажите о проекте, которым вы больше всего гордитесь, и объясните, почему именно им?»
Остерегайтесь ответов, сфокусированных только на технологическом зуме: «Мы гордимся проектом, где использовали блокчейн и машинное обучение на микросервисной архитектуре!». Это гордость за инструменты, а не за результат.
Ищите ответ, в центре которого – влияние, преодоление или человеческие отношения.
- Гордость влиянием: «Мы гордимся проектом для небольшой региональной сети аптек. У них был допотопный учет, и мы сделали для них простую, но идеально заточенную под их процессы систему».
- Гордость преодолением: «Самый сложный проект – это «спасение» системы, которую делала другая команда 2 года и бросила в полурабочем состоянии. Мы не просто довели его до ума, мы полностью перепроектировали ядро. Гордимся не тем, что мы сделали с нуля, а тем, что мы смогли вернуть клиенту веру в то, что его идея жизнеспособна».
- Гордость отношениями: «Есть клиент, с которым мы работаем уже 8 лет. Начинали с маленького лендинга, а сейчас ведем всю его цифровую экосистему. Мы пережили вместе несколько кризисов, полную смену их бизнес-модели и растем вместе».
Разработка ПО от 66 Бит
Всего за 10 минут вы разобрались во всех важных аспектах, которые необходимо уточнить у подрядчика перед тем как ставить подпись! Теперь можно смело выходить в свободное плавание на поиски того единственного.
Но чтобы облегчить вам эту задачу, советуем обратить в 66 Бит! Наши опытные специалисты не только ответят на все перечисленные вопросы, но и разработают эффективное и качественное ПО, учитывающее специфику бизнеса и ваши бизнес-процессы! Подробнее читайте на нашем сайте по ссылке.