[business.mistake] Проиллюстрирую свои недостатки, пожалуй...

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

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

Преамбула

Итак, некоторое время назад внезапно объявился клиент, который когда-то нашими услугами уже пользовался. И, в принципе, в курсе особенностей моей работы, так что традиционное "нужно подумать" не должно было бы его удивлять.

Речь зашла о том, что им нужно быстро сделать обработку графа социальных связей. Проблема из категории тех, которые решаются в FB, VK, Twitter, Instagram, LinkedIn, когда нужно формировать и обновлять ленту новостей у пользователя. На масштабах, которые поменьше, чем у вышеозначенных соцсетей, конечно, но в пределе виделось несколько сот миллионов пользователей у некоторых из которых могут быть миллионы контактов.

В какой-то момент разговор принял приблизительно такой вид:

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

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

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

Два дня на то, чтобы понять в чем проблема, серьезно?

Итак, откуда берется оценка в 1-2 дня только на ознакомления с темой? Вот что-то вроде перечня пунктов, которые проносятся у меня в голове когда меня просят озвучить предполагаемые сроки:

• нужно ознакомиться с тем, что за данные в проекте у клиента: где, в каком виде, сколько их, какие особенности, что конкретно нужно получить и из чего именно это нужно получать. Когда человек уже варится в проекте, это все для него очевидно, но для стороннего разработчика, который даже о задаче такой ни сном, ни духом, не говоря уже о конкретных структурах данных в конкретном проекте, это большое белое пятно. Время на знакомство с этой информацией предсказать трудно: хорошо, если тебе сразу дадут контакт знающего программиста, который сможет выдать все это в концентрированном и структурированном виде. Тогда задержка будет только с тем, чтобы уложить это все в собственную башку. Но, если исходить из опыта прошлого, в коммуникациях всегда возникают какие-то задержки и недопонимания. А это все время, расход которого сложно прогнозировать. Тут 5 минут, там 15, здесь еще 10. И, глядишь, 30-60 минут рабочего времени уже куда-то девалось;
• нужно познакомиться с технологическим стеком проекта, нужно разобраться с тем, каким образом можно будет обмениваться информацией между теми модулями, которые уже есть (и которые с 99.9(9)% вероятностью написаны не на C++), и тем модулем, который предстоит написать тебе. Здесь точность предсказаний такая же, как и в предыдущем пункте;
• нужно хотя бы бегло прошерстить Интернет и прочитать хотя бы 3-4 статьи на эту тему. Помнится, лет 5-7 назад обсуждение проблем обработки социальных графов в соцсетях была модной и публикации с рассказами о том, что и как делается, встречались регулярно. Но я-то помню только о том, что такие публикации были, сам я эти задачи не решал. Так что здесь придется усваивать много нового. Плюс к тому, вероятно, придется что-то перечитать по графам, просто для того, чтобы восстановить университетские знания на эту тему. А еще может быть необходимо ознакомиться с готовыми библиотеками работы с графами и составить впечатления об их возможностях/требованиях. Берем по полчаса на статью и вот у нас еще несколько часов улетело;
• нужно как-то уложить это все в голове в структурированном виде. Еще раз осознать в чем именно состоит проблема. И составить перечень из двух-трех возможных вариантов ее решения. Хотя, тут может повезти и оказаться, что такой вариант всего один. Но на везение лучше не расcчитывать;
• нужно прикинуть какими именно средствами я могу решать эту задачу. И, вероятно, что-то нужно будет освежить в памяти. А с чем-то придется познакомиться впервые.

Добавим сюда еще и то, что с годами резко врубаться в новую тему становится все сложнее, соображаю я уже далеко не так быстро, как раньше. И сейчас мне на обдумывание нужно несколько больше времени, чем 20 лет назад.

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

И это было только время на погружение в тему, далее можно коснуться реализации

Итак, я C++ разработчик. Т.е. сходу могу начать клепать код на C++. Либо на C (хотя это явно будет медленнее). В крайнем случае на Ruby, т.к. Ruby время от времени применяю для вспомогательных задач и какой-то необходимый минимум знаний Ruby еще остается.

В принципе, можно и на Java (тогда нужно будет дня два-три чтобы вспомнить язык, хотя там основная проблема не в языке, а в библиотеках/фреймворках, которых я практически не знаю). Или на Go, или Python. Но это еще плюс неделя на прокачку, т.к. HelloWorld-ы на этих языках я писал уже довольно давно.

Поскольку задача срочная, то рассматривать варианты с Java/Go/Python не приходится. Значит, остается C++.

Запрограммировать некий алгоритм обработки больших графов, протестировать еще и убедиться, что написанный код пригоден для продакшена, да на C++...

Как по мне, так наивно рассчитывать, что все это можно сделать меньше, чем за один день.

Добавим сюда еще и то, что сам по себе алгоритм -- это лишь полдела. Нужен модуль, который как-то будет взаимодействовать с другими модулями, которые явно не на C++.

А значит нужно будет подтягивать какие-то механизмы для обеспечения интероперабельности. Будь-то какой-нибудь REST API, gRPC, MQ-шный брокер или даже простой обмен данными через (no)SQL DBMS.

К сожалению, в C++ подобные вещи не идут "из коробки". Это все нужно подтягивать и устанавливать. Более того, большинство инструментов, реализующих подобные вещи, для меня внове. Мне придется их изучать, т.к., например, с gRPC или AMQP я пока что ни разу не сталкивался.

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

Это все субъективные оценки

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

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

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

Бонус: пару слов про озвучивания оценок в телефонных разговорах

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

• не отпугнула потенциального клиента и выглядела бы в его глазах более-менее оптимистично;
• оставляла тебе самому хоть какие-то шансы не облажаться из-за постоянных переносов сроков;
• выглядела бы экономически оправданной для тебя самого. Ибо далеко не всегда есть смысл срываться с места чтобы потратить один рабочий день на левую задачу, которая принесет, максимум, $200 выручки. И непонятно сколько геморроя в будущем.

Так что лично я очень не люблю подобные моменты в переговорах. Гораздо лучше получается, когда ты просишь и получаешь некоторый тайм-аут на первичное ознакомление. Т.к. бывает, что 15 минут гугления создают намного более адекватную картинку, чем то, что складывается в процессе телефонного разговора с потенциальным клиентом.

Поэтому я стараюсь выслушать описание проблемы клиента. Затем беру тайм-аут в течении которого время от времени задаю уточняющие вопросы. И лишь затем высказываю свои соображения с вилкой из оптимистичного и пессимистичного сценария.

Стараюсь, но не всегда такое оказывается возможным.

Напоследок философское про совпадение заказчик/исполнитель

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

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

Вот такое вот у меня пока что убеждение. Может быть ошибочное, но уж какое есть :)

Можно, конечно, бросаться на все подряд и обещать свернуть горы уже к концу рабочего дня. Но, имхо, криворуких обещунов и так много, затем же пополнять их количество?