Это продолжение статьи про стоимость часа.

Наш уважаемый читатель моего блога Дмитрий Покровский в комментариях к предыдущей статье про стоимость часа задал хороший вопрос о том, как оценивать работу, если задачи поставлены нечётко и ТЗ постоянно меняется, либо если код недостаточно изучен.

Это послужило для меня поводом написать новую статью, чтобы раскрыть поднятую тему.

Мы в Creative Force регулярно имеем дело с такими проектами и, тем не менее, продолжаем придерживаться своей философии с оплатой за результат. И здесь ключевое слово - результат. Да, действительно, периодически бывают проекты, в которых конечная задача поставлена недостаточно чётко. В таких проектах уместно работать по итеративной модели, и делать быстро что-то небольшое, показывая это заказчику (или рынку) и получая обратную связь, далее строя свою работу на основании этой обратной связи. Подробнее этот процесс описан в следующей интересной статье про разработку интерфейса Windows 95.

В таких случаях мы договариваемся о бюджете за конечный результат, независимо от того, какими путями мы к нему придём в конечном итоге. Например, делаем сейчас географический проект для Казахстана (логин: cfteamuser, пароль: cfteamuser). В нём конечная задача была поставлена просто: к 10 июня 2018 г. сделать демо для конференции. Были описаны общие требования, что должно было быть реализовано — то есть, задача была поставлена на уровне бизнеса. Это уровень над программированием, над самим проектом — это о том, что ожидает получить клиент. Мы не говорили ни про технологии, ни про трудозатраты, ни про фреймворки (кроме обоснованного требования использовать Cesium). Мы обсудили идеальный конечный результат, стоимость, сроки, и приступили к работе.

Первое демо было готово уже через несколько дней. Это был развёрнутый на нашем хостинге фреймворк Bricks Pro моей разработки, в модуле карты отображалась карта с одной точкой, и далее мы приступили к формированию базы данных.

В ходе работы, как я и предполагал, обнаружилось много подводных камней и особенностей. Например, для отображения точек на поверхности ландшафта нужно было для каждой пары координат посчитать высоту. Использовали Google Maps Elevation API, для каждой пары координат получили высоту над уровнем моря в метрах, что и было необходимо (чтобы разгрузить фронтэнд и избавить его от лишних вычислений). Как оказалось, в Google данные точнее, чем в Cesium.

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

Короче говоря, увидев первую версию проекта, клиент начал выкатывать поправки и корректировать дальнейшую работу, и мы стали двигаться в этом направлении.
При этом 1-2 раза в неделю у меня выходные, когда я могу себе позволить подумать над архитектурой и более грамотной реализацией дальнейших шагов. Никто не считает, сколько времени я потратил на работу (кроме thesystem, в которой мы, разумеется, ведём задачи), никто не ждёт меня в офисе к 10, мне не приходится стоять в пробках, я успеваю заниматься музыкой, строить дом, общаться с людьми, уделять внимание моей спутнице жизни, полноценно высыпаться, читать книги, и даже ездить на природу с весёлой компанией и путешествовать. При этом я зарабатываю больше, чем среднестатистический московский программист, который также тратит деньги на аренду жилья и время на дорогу, и завязан на своей работе, в которой нет просвета.

Подводя итог, хочу заметить, что в некоторых проектах неадекватно ждать законченное ТЗ, при том, что предпринимательство — это, как правило, действия в условиях неопределённости. Если проект — стартап, или что-то подобное с непонятной моделью монетизации, или нужно сделать технологический прорыв (как в случае с Windows 95) — то итеративная разработка в таких проектах решает. Просто на старте нужно закладывать риски многократного переделывания и изготовления большого количества прототипов для тестов. Если же работать с оплатой за время — то у клиента просто внезапно могут кончиться деньги (как у нас недавно случилось в другом проекте — результат нарушения своих же заветов).

На этой неделе у нас на горизонте появился другой, не менее амбициозный проект, за который мы уже взялись. Раскрывать карты по нему пока рано :)

Мир IT неуклонно идёт к тому, что всё больше и больше разработчиков становятся фрилансерами, а самые крутые из них отвечают за результаты на уровнях, которые не имеют ничего общего с программированием как таковым. Самый крутой уровень ответственности — это отвечать за конечную прибыль компании. Команды, которые смогут работать на этом уровне, при этом выдерживая сроки и полностью выполняя взятые на себя обязательства — станут новыми лидерами рынка в 21 веке. Поэтому Creative Force взяла курс именно на этот уровень ответственности.

На фото: остатки замка в западной Беларуси.