Часы работы: 10 - 19 (Москва)

г. Пенза, ул. Суворова 64б, 6 этаж

История неуспеха

История неуспеха

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

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

О чем проект?

Суть бизнеса заказчика заключается в оптовой перепродаже VoIP-трафика (голосовых звонков через Интернет) более мелким поставщикам VoIP-сервисов. Прибыль у таких компаний состоит из разницы в цене продажи трафика и достаточно низких закупочных цен.

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

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

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

Разногласия на этапе обсуждения

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

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

Всего было нужно проанализировать порядка 10 миллионов записей. Предложение CodeInside состояло в том, что компания выделяет опытного специалиста, а оплата идет по фактическим затратам (схема time & materials). Заказчик согласился, и работа стартовала.

Начало работы

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

В формате “time & materials” вмешательство со стороны менеджмента обычно минимально, но тут, увы, не обошлось без вмешательства и непростого построения процесса совместной работы. Для начала мы попытались договорились использовать трекер для ведения задач, а не чат, где задачи могли легко потеряться.

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

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

В какой-то момент контракт оказался под угрозой, но заказчик вовремя согласился продолжить работу. Так как со стороны Codeinside было потрачено уже много сил на исследование, решение оказалось не загорами. Сработала закономерность: чем дольше бьешься над задачей, тем ближе решение.

Нетривиальное решение

Интенсивная совместная работа с заказчиком помогла нам выйти на новый уровень решения. Его экспертные знания в области онлайн-телефонии (VoIP) помогли нам больше, чем попытки построить универсальную математическую модель.

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

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

Вывод

Сотрудничество по схеме time & materials — оптимальный формат работы в случаях, когда нужно решить проект быстро, и когда нет времени составлять ТЗ для полной передачи проекта на внешнее исполнение. Этот формат подходит компаниям, которые уже имеют опыт руководства командами разработчиков, либо сами принимали участие в разработке в прошлом. Быстро подобранная команда CodeInside — это “профессиональный инструмент”, чтобы умело его использовать, важны квалификация и опыт, если этого нет, то все может пойти наперекосяк.

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

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




История неуспеха