60 дней фильмов и сериалов
по промокоду:
VC60
Забрать
60 дней подписки Яндекс Плюс бесплатно для новых пользователей, ранее не оформлявших подписку Яндекс Плюс либо подписки, её включающие, при условии привязки банковской карты. Далее — автопродление: 199 ₽/месяц. Действует на территории РФ. Активировать до 31.10.2021 г. https://hd.kinopoisk.ru/gift. Условия: clck.ru/FMQND.
Личный опыт
Alexey Poimtsev

Как заказчику работать с внешней командой разработки

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

Клиент не всегда прав

Хочу развеять один популярный стереотип, который звучит как “клиент всегда прав”. Некоторые заказчики мотивируют его тем, что они платят деньги и имеют полное право на то, чтобы любое их решение считалось единственно верным и не требовало обсуждения. К сожалению — это не так. Как клиент вы точно также заинтересованы в разработанном продукте, как и разработчик — в вашем заказе. Любая из сторон имеет полное право выйти из контракта, если его что-то не устраивает и если заказчик начнёт вести себя как мудак, то адекватным исполнителям ничего не останется кроме как прекратить сотрудничество. В таком случае клиенту придётся искать других разработчиков, уедут сроки, будут потрачены лишние деньги и так далее. Вы в этом заинтересованы? Уверен, что нет.

Работа с документами

Все знают, но мало кто делает, но на каждый чих надо подписывать документы. Я не устаю это повторять. Должен быть договор, перечень работ, техническое задание, счёт на оплату и акт. В ряде случаев было бы неплохо подписать NDA, но в России его применимость под очень большим вопросом.

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

Я встречал разные договоры, самые интересные наблюдения из того, что я видел:

  • Договор, составленный из копипаста статей ГК РФ. Таким образом договор не защищал никого (ни разработчика, ни заказчика), более того — юридически было возможно разработчику получить предоплату и ничего не делать, а заказчик отправлял бы правки, которые можно было отвергать, ссылаясь на недостаток информации. Не имея возможности изменить этот договор (юристы компании тупо отказались его править) нам пришлось отказаться от этого клиента, хотя проект был достаточно интересный
  • Договор, по которому заказчик имеет право в одностороннем порядке уменьшить стоимость работ. Вот тут признаюсь честно — я налетел на грабли. Нам повезло, что стоимость контракта была небольшой, но из-за того, что на стороне заказчика был далеко не самый профессиональный менеджер — нам затянули сроки с предоставлением информации и в результате чего мы сорвали сроки и пришлось вернуть предоплату (согласно договору они уменьшили его стоимость. Позже я обсудил с другим юристом — технически мы могли отказаться от возврата)
  • Договор с нереальными сроками, но с “вкусным” ценником. Ну тут комментарии излишни — вписываться в такой проект, когда ты рискуешь влететь на штрафы вменяемый человек не захочет. Мы отказали этому клиенту.
  • Договор, в котором права на выполненные работы остались у разработчиков. Помните — вы платите за то, что продукт пишется ДЛЯ ВАС. Эта компания потом конкурировала с аутсорсерами, которые получили деньги за то, что писали клиенту код.

Работа над продуктом и ТЗ

Один из первых вопросов, который задают нам “А у вас есть бриф для заполнения?” или “В каком формате присылать ТЗ?”. В разных компаниях подходы разные, но в большинстве своём компании-аутсорсеры не думают над тем, кто и как будет пользоваться продуктом, сваливая ответственность за неудачные продуктовые решения на заказчика. Мы в Progress Engine пошли другим путём — под каждый проект выделяется свой продукт-менеджер, который помогает клиенту понять, что он хочет, как и кто будет этим продуктом пользоваться. Если мы видим, что клиент не совсем корректно формулирует требования к продукту – мы стараемся ему помочь, отталкиваясь от нашего опыта и опыта коллег по рынку. Если же разработчики не участвуют в анализе продукта и не подвергают критике каждое некорректное решение заказчика, то это – халтурная работа.

Идеальный вариант перед началом работ заказать продуктовую аналитику у тех, кто в этом специализируется. Результатом будут:

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

Разработка

На предыдущем этапе мы определились с роадмапом. Теперь нам важно выстроить таким образом процесс разработки, чтобы она шла максимально эффективно. Пара ключевых моментов:

  • В идеале на вашей стороне должен быть хоть один человек, разбирающийся в технологической части проекта. Не обязательно крутой разработчик, но опыт управления проектами и знание используемого стека технологий у него быть должны
  • Раз в неделю необходимо созваниваться с разработчиками и получать статус и давать обратную связь.
  • Раз в неделю или максимум раз в 2 недели разработчики должны закрывать очередной этап разработки. Итогом будет работающий продукт с определёнными заранее функциями.
  • Весь код должен быть регулярно передан вам, например отправлен в ваш репозитарий на GitHub
  • У вас должно быть как минимум 3 окружения (проще говоря — сервера). Development — окружение, где будут “резвиться” разработчики. Staging — на котором вы как заказчик будете принимать работы. Production — боевое окружение, к которому имеют доступ ваши пользователи.
  • После завершения каждого этапа (спринта) у вас должен быть подписан акт, что вы не имеете претензий к разработчикам, а они передают вам исключительные права на код

TL;DR или итоговый чеклист

  • Выбирать разработчиков, отталкиваясь не от цены, а от качества предоставляемых ими услуг. В ряде случаев имеет смысл работать с ними по схеме time and material (почасовая оплата) — вы оплачиваете только то время, которое они выработали и имеете возможность гибко управлять объёмом работы
  • Выбирать разработчика, которые будут думать с вами о том, как пользователи будут использовать этот продукт и будут советовать как его улучшить. Качество советов определяет ценность разработчиков.
  • Подписать рамочный договор, защищающий интересы обеих сторон
  • Подписать приложение к рамочному договору, в котором чётко прописаны работы, их стоимость и критерии приёмки
  • Проверить, что все права на выполненные работы принадлежат вам и это прописано в договоре
  • Разбить работы на этапы, определить стоимость каждого этапа
  • Проводить оплату работ не единоразовым платежом, а оплачивать каждый этап. Это позволит вам быстро сменить разработчика в случае проблем с ним, а он не будет расслабляться, зная, что у него все деньги уже на счету и можно работать расслабленно.
  • Проведите продуктовое исследование. На выходе вы получите ТЗ, Roadmap, декомпозицию с предварительной оценкой стоимости и интерактивный прототип
  • Все заведённые для проекта аккаунты должны быть оформлены на вашу компанию — почтовые ящики в вашем домене, оплата с корпоративного счёта, руководство имеет доступ, в случае если ответственный человек на стороне заказчика решит уволиться
  • Должны быть еженедельные конференц-коллы с разработчиками, которые должны сообщать вам статус и отчитываться о выполненной работе.
  • Раз в 1–2 недели разработчики должны закрывать перед вами очередной этап разработки. По результату код должен быть “отгружен” вам в систему контроля версий
  • Должно быть 3 окружения — development, staging, production
  • Весь код должен быть протестирован не только разработчиками, но и вами. Идеально — если будут написаны автоматические тесты
{ "author_name": "Alexey Poimtsev", "author_type": "self", "tags": [], "comments": 2, "likes": 15, "favorites": 43, "is_advertisement": false, "subsite_label": "life", "id": 51472, "is_wide": true, "is_ugc": true, "date": "Thu, 22 Nov 2018 14:35:13 +0300", "is_special": false }
0
2 комментария
Популярные
По порядку

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

У меня клиенты часто спрашивают кого посоветуете для мобильной разработки - могу ли получить позже консультации в привате?

3

Да - без проблем. Email есть на сайте, я его регулярно проверяю :)

0
Читать все 2 комментария
Apple лучшая компания 2021 года
Как OTUS стал платформой для самореализации. История преподавателя

Наш преподаватель, специалист по Data Science, решил поделиться своей историей преподавания. Он рассказал, как пришел в эту сферу, с какими трудностями столкнулся на пути к преподаванию и что ему помогает. А еще поделился советами, как поддерживать внимание студентов и сделать занятия полезными и увлекательными.

Маркетинг здорового нечеловека: 3 сервиса для автоматизации маркетинга малого бизнеса

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

Скрин личного кабинета
Исследование: сотрудники хотели бы иметь комнату отдыха, бесплатный сок, а работодатели уже готовы покупать ЗОЖ-снеки

Онлайн-сервис доставки продуктов и товаров СберМаркет и исследовательское агентство Research Me спросили сотрудников, как они хотели бы питаться в офисе и что в нем видеть. В опросе приняли участие более 1500 работающих людей по всей России. Сервис также спросил работодателей – В2В-клиентов СберМаркета: что они покупают в офис, что точно никогда…

DevOps для бизнеса. Наш опыт и выводы

Обратили внимание, что запросов на DevOps-инженеров с одной стороны стало больше, а с другой стороны, не все кто их ищет, правильно понимают, что такое DevOps и как это работает. Мы собрали и структурировали свой опыт, чтобы разъяснить, в каких случаях нужен DevOps, а когда можно обойтись и без него.

ПСБ запустил личный кабинет для предпринимателей. Там можно следить онлайн за каждым своим терминалом

Сервис предоставляется бесплатно.

Cloud CDN: что это такое, как устроено и кому нужно. Разбираем на примере бургеров

Cloud CDN — это сеть быстрой доставки статического контента в формате услуги облачного провайдера. Объяснить, как работает технология, проще всего на примере — сравнить Cloud CDN с популярным продуктом, который выглядит плюс-минус одинаково вне зависимости от того, заказали вы его в Москве, Питере или Нью-Йорке. Знакомьтесь: классический бургер.…

«Яндекс.Маркет» не может доставить товар

Заказал на яндекс-маркете яндекс-станцию + яндекс-модуль, списать денюжки у маркета личико не треснуло, а вот с доставкой началось откровенное издевательство.

Правительство обязало мессенджеры регистрировать пользователей по паспортным данным с марта 2022 года Статьи редакции

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

Как не попасть в карьерную ловушку тимлида: личный опыт

Кажется, что тимлиду просто некуда расти: дальше надо либо идти в менеджмент, либо наоборот, становиться узконаправленным разработчиком. По просьбе «Лаборатории Касперского» Евгений Мацюк, который прошел в компании неординарный путь, рассказал о своих карьерных развилках во время и после тимлидства, а также поделился опытом горизонтального роста.

Нейрохакинг #8. Фонтурацетам (фенотропил)

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

null