Не знаешь что выбрать — спроси у заказчика

Как понять, что вы делаете что-то не так

Если вы писали что-то похожее своему заказчику, ПМу или даже знакомым, прочитайте статью, и вы узнаете, почему вы не правы:

Зачем читать эту статью

• Как задать вопрос заказчику, чтобы он вас понял.
• Как продать тех. решение, которое вы хотите внедрить.

Спрашивайте так, чтобы вас поняли

Представьте, у вас на выбор 2 библиотеки: python-telegram-bot и aiogram.

 В чём разница?

По первой много туториалов, есть примеры использования прямо в репозитории. По второй тоже много туториалов и примеров, но писать надо будет на асинхронном Python, которым моя команда не владеет. Это даст возможность оптимизации бота под огромные нагрузки в далёком будущем.

Если вы не уверены что выбрать — можно уточнить у ПМа или заказчика. Только не надо спрашивать так:

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

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

Общение представителей бизнеса с разработчиками должно быть ежедневным на протяжении всего проекта, п. 4 Манифеста Agile

Делайте так, чтобы вам было просто ответить

Обратите внимание на эту часть:

Тут произошло две важные вещи:

1. Вы обозначили срочность
2. Дали путь к отступлению

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

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

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

Лучше всего, если вы пришлёте что-то да/нетное, то есть такой вопрос, на который можно ответить “да” или “нет”.

Если вопрос будет слишком сложным и при этом у заказчика/ПМа не будет возможности быстро узнать, что он хочет на самом деле – велика вероятность, что вам ответят наугад. А потом придётся переделывать, потому что оказалось, что заказчик не угадал 🤷‍♂️

Вот ещё один пример:

О чём думает заказчик:

• Что такое пагинация?
• Что за шаг пагинации?
• И как мне узнать, с каким шагом, блин?

Ответы на эти вопросы закачик не знает. Он может конечно загуглить “пагинацию”, но это потребует времени. Чем больше нужно думать и гуглить, чтобы ответить на ваш вопрос – тем меньше на него хочется отвечать.

Тот же вопрос, но сформулированный так, чтобы на него было проще ответить:

• Не нужно знать что такое пагинация
• Оказывается, ну нужно какое-то точное число. Можно выбрать одну из “прикидок”
• Предусмотрели “будущее”, может ли линейка товаров расшириться. В первом случае заказчик мог об этом не подумать
• Понятно зачем меня спрашивают, даже могу себе визуально представить, за счёт картинки

Чем проще вопрос, тем лучше ответ

А зачем мне всё это? Это же ему нужен сайт, а не мне

Отличный вопрос!

Действительно, можно общаться с заказчиком и теми сообщениями, что приведены в примере “как не надо”. И вам всё равно ответят, и может быть даже не будут считать мудаком.

Деловая переписка – это в первую очередь дело и уже потом – отношения. Люди каждый день приходят на работу, которую ненавидят, чтобы исполнять поручения, которые не понимают, от начальства, которое презирают. Мир работает и без уважения.

Другое дело, что на уважительные письма мы откликаемся гораздо лучше, чем на обычные. Мы отвечаем быстрее, больше «включаемся», находим нестандартные решения, работаем с удовольствием, меньше устаём и в итоге становимся продуктивнее. Это не значит, что плохо написанные письма мы игнорируем. Нет, конечно. Это же работа.

«Новые правила деловой переписки» Максим Ильяхов, Людмила Сарычева

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

«С этим человеком приятно работать» – почти безграничный источник профитов

Заказчику не нужны крутые технологии

Это не очевидная идея для многих разработчиков, но технологии не являются хорошими сами по себе. Высокая нагрузка нужна не всем. Логирование, Докер и даже база данных не являются обязательными для хорошего проекта. Перед тем, как добавлять в проект новую технологию, задайте себе вопрос: «в чём польза от этой технологии для заказчика? Какой у нас есть под это бюджет?» Например, может так оказаться, что даже база данных вам просто не нужна, её можно заменить обычным excel-файлом, если это дешевле и удобнее для клиента.

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

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

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

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

Докер стал популярным не просто так, его за что-то любят. Если хотите добавить его в проект — говорите не о том, что “это круто”, а объясняйте, почему это выгодно. Пример сообщения заказчику:

В каких-то вопросах заказчик знает больше, чем вы. Например, что разработка ведется просто ради мокапа, за который заказчику заплатят, а продакшна не будет вовсе! Если заказчик не прав — попробуйте объяснить, что он не прав. Но держите в голове, что иногда всё же не правы вы. Учитесь договариваться.

Или, если хочется провести рефакторинг — это же тоже заказчику ни в какой вселенной не нужно. Зачем ему платить за то, что вы переделываете прошлую работу? Но если объяснить, то ему станет нужен и рефакторинг:

Нужно всё переписать

Это вообще любимая новичковая проблема. Почти каждый новичок, особенно после Девмана, с этим сталкивается.

Вот цензурная версия как это выглядело у меня:

Это непрофессионально, и спустя призму лет мне стыдно за такую свою реакцию.

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

Это нормальная практика с ней придётся смириться. Заказчику не важно, как хорошо написан код. Заказчику важно, чтобы были реализованы фичи, о которых вы договаривались. Постоянное стихийное исправление тех. долга мешает прогнозировать сроки разработки: заказчик не знает, когда его фичи буду готовы. Потеря гибкости управления – это самая страшная беда для бизнеса.

Ещё одна неочевидная мысль: а кто сказал, что новый код будет без багов?. Об этом разработчики тоже часто забывают. Никто не хочет думать о своём коде как о забагованном. А ведь если “переписывать” вы будете больше 50 строк кода – туда наверняка закрадутся новые баги, которые захочет переписать следующий программист, который добавит туда своих багов…

Про сроки: любые “перепишу за 30 минут” – обычно хвастовство и бахвальство перед вашим предшественником, чей код вы собрались переписывать. Скорее всего вы не уложитесь в оценку и вольёте в переписывание больше дня.

Также программисты же могут “заиграться” и перестать отслеживать пользу от своих исправлений. Некоторые ребята начнут тратить недели на бесполезный рефакторинг, от которого нет пользы. Например, совершенно нет никакой пользы в рефакторинге одноразовых скриптов, которые вы запустите один раз (для подсчёта статистики, например) и забудете о них навсегда.

Иногда придётся даже умышленно костылить в угоду дедлайнам.

Пример из жизни

Коллега переносил часть сайта с Java на Python. Он успел перенести каталог товаров и поиск по ним. Но не успел расправиться с расчётом цены. Он пошёл на хитрость: код на Python делает запрос по сети к старой версии сайта, на Java, и запрашивает цену товара у неё.

Костыль? Конечно. Придётся держать запущенной старую версию сайта на Java. Звучит как просто кошмар. Но если посмотреть чуть шире, то станут заметны профиты от этого решения:

• Задача закрыта в срок, интерфейс теперь на Python
• Другие отделы, которые должны были подключиться к новому интерфейсу (мобильные приложения и фронтенд) – уже могут начать с ним работу
• Все фичи от переезда на Python, которых хотели добиться – получены

Теперь с руководством можно согласовать окончательное выпиливание старой версии на Java не блокируя все остальные команды, которые ждали интерфейс на Python.

По-моему отличный пример, когда костыль может быть крутым, профессиональным решением.

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

И что же, чистота кода никому не нужна?

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

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

Часто “чистый код” — это “потрачу на 10 минут больше сейчас, чтобы потратить на 2 часа меньше потом, через месяц”.

Так вот если “потом” наступит через месяц или совсем никогда — ничего страшного, можно оставить немного тех. долга.

Если “потом” наступит завтра, когда сокомандник откроет ваш код — надо рефакторить сейчас. Потратите лишний час, зато ваш сокомандник не потратит лишние три.

Чистота кода нужна, но в меру

Хочу ещё!

Видео на ту же тему, которое мы нашли на YouTube: