Сроки

Не раз я сталкивался с удивлением при оглашении оценки сложности проекта: А почему так долго?, Да тут же раз, два и готово!, Можно же просто взять X и сунуть в Y!. Программисты привыкли оценивать сроки как время на написание и отладку кода, хотя в крупные задачи входит ещё много всего.


Знаете ли вы, что в реальности айсберги располагаются в воде горизонтально, а не вертикально, как на большинстве стоковых картинок?

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

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

Поиск по пользователям

Одним из крупных разделов приложения Joom является внутренняя социальная сеть, где покупатели могут писать обзоры на товары, лайкать и обсуждать их и подписываться друг на друга. А какая же соцсеть без поиска по пользователям!

Конечно, поиск нельзя назвать такой уж лёгкой на вид задачей (по крайней мере после моей предыдущей статьи). Но я уже обладал всеми нужными знаниями, а также у нас в компании был готовый компонент joom-mongo-connector, который умел переливать данные из коллекции в MongoDB в индекс Elasticsearch, при необходимости приджойнивая дополнительные данные и делая какую-то ещё постобработку. Задача звучала довольно просто.

Задача. Сделай бэкенд для поиска по пользователям соцсети. Фильтров не надо, сортировка по количеству подписчиков сойдёт для начала.

Окей, это правда звучит просто. Настраиваем переливку из коллекции socialUsers в Elasticsearch путём написания конфига на YAML. На бэкенде добавляем новый эндпоинт с API, аналогичным API поиска товаров, только пока что без поддержки фильтров и сортировок (остаются только текст запроса и пагинация, всего-то). В хендлере делаем простейший запрос в Elasticsearch-кластер (главное не ошибиться кластером!), из результата достаём ID нашедшихся документов, они же ID пользователей по ним самих пользователей, потом конвертируем в клиентский JSON, пряча от посторонних глаз приватную информацию, и готово. Или нет?

Первая проблема, с которой мы столкнулись транслитерация. Имена пользователей брались из соцсетей, где пользователи из России (а их на тот момент было большинство) часто писали их латиницей. Пытаешься найти Мадса, а он в фейсбуке Mads, и всё нет его в результатах. Аналогично по Ivan не получится найти Ивана, а очень хотелось бы.

Вот и первое усложнение при индексации мы стали ходить в Microsoft Translator API за транслитерацией и сохранять две версии имени и фамилии, а общий индексирующий компонент стал зависеть от клиента транслитератора (и зависит до сих пор).

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

Так что следующее усложнение заключалось в том, что мы нашли на Грамоте.ру указатель уменьшительных имён (из единственного в своём роде словаря русских имён Никандра Александровича Петровского), добавили в кодовую базу в качестве захардкоженной таблички (какие-то две тысячи строк) и стали индексировать не только имя и его транслитерацию, но и все найденные уменьшительные формы (fun fact: в английском языке для них есть термин hypocorisms). Мы брали каждое слово в имени пользователя и делали лукап в нашей скромной таблице.


Нотариально заверенный скриншот кодовой базы Joom. Circa 2018.

Но потом, чтобы не обидеть вторую половину наших пользователей, распределённую неровным слоем по нерусскоговорящему миру, мы кинули клич кантри-менеджерам Joom и попросили их найти нам справочники сокращений национальных имён в их странах. Если не академические, то хоть какие-нибудь. И выяснилось, что в некоторых языках, помимо традиции иметь сложносоставное имя (Juan Carlos, Maria Aurora), также существуют сокращения двух, трёх или даже четырёх слов в одно (Mara de las Nieves Marinieves).

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

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

Машинный перевод товаров

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

Все, наверное, видели мемы про кривой перевод названий китайских товаров. Мы тоже их видели, но желаемое time to market не позволяло придумывать что-то лучше, чем использование какого-то существующего API для перевода.

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

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

После запуска качество переводов, конечно же, не давало нам покоя, и мы подумали: а что, если использовать более дорогой переводчик? Но будет ли он хорош на наших специфических текстах? На глаз их не сравнишь, нужно проводить A/B-тест. Так в нашем кэше переводов помимо ID товара появился ID переводчика, и мы стали запрашивать перевод с ID переводчика, зависящим от того, в какую группу A/B-теста попал пользователь.

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

Потом решили, что некоторые магазины на платформе настолько хороши и платформа так болеет за их успех, что готова переводить их товары более дорогим переводчиком всегда. Так логика выбора переводчика стала зависеть от пользователя, страны и ID магазина.

И наконец, мы решили, что за несколько лет существования Joom наш основной переводчик мог улучшиться, и, возможно, кэш переводов имеет смысл обновлять с какой-то периодичностью. Но как же без A/B-теста? Так в нашем кэше появилось поле freshness, и всё усложнилось ещё раз. В итоге наша компонента, занимающаяся переводом, невероятно сложна, и это при том, что мы даже ещё не прикрутили туда никакой самодельной вычислительной лингвистики. Пока что.

Конвертация размеров одежды

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

Дополнительно проблема усложняется тем, что продавцы из разных стран могут иметь совершенно разное представление о размерах. Китайский M легко может оказаться русским XS, а ужасающий 9XL не так уж сильно отличаться от XXL. Прошаренным пользователям приходится ориентироваться на замеры, но и те не всегда верны: например, пользователь ожидает, что указан обхват груди человека, а продавец указывает измерения самой одежды они отличаются процентов на пять-десять. Мы не хотим, чтобы пользователю нужно было так заморачиваться для шоппинга на Joom!

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

Окей. Берём таблицу размеров, которая у нас парсится из описания товара (этим занимается отдельный космолёт на 5к строк) и хранится отдельным полем, и подменяем в ней размеры на вычисленные. Хардкодим таблицу для конвертации обхвата в размер, найденную в интернете, и радуемся жизни.

Но если таблицы нет или в ней не хватает строк, это не работает. Фича отключается на товаре неявным образом номер раз.

Хм, в таблице обхваты тела человека, а большинство продавцов указывает их, померив на самих вещах. Вшиваем коэффициент разницы. Продакт-менеджер Родион, счастливый обладатель идеальной М-ки, идёт в торговый центр, меряет на себе кучу разных вещей и приходит с коэффициентами они похожи, но существенно различаются для разных категорий товаров. Для обхватывающей водолазки разница практически 0%, а для свитера все 10%. Также верхняя одежда различается по посадке: slim fit, normal fit, loose fit, и это даёт размах ещё в 5%. Теперь наш коэффициент (увековеченный мною в коде как коэффициент Родиона) состоит из двух множителей.

Для определения посадки делаем ещё один парсер, пытающийся извлечь её из названия или описания товара. Если товар не попал в одну из категорий, проверенных Родионом, фича выключается неявным образом номер два.

Финальный штрих: в большом количестве товаров обхват груди указан от подмышки до подмышки, то есть только половина обхвата, что приводит к смехотворно маленьким размерам. Добавляем логику, что если обхват меньше X, то ну не может такого быть, это явно половина обхвата, и умножаем его на два. Хорошо, что взрослые люди обычно не отличаются друг от друга обхватом груди в два раза.

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

И всё это работает по-разному в зависимости от группы A/B-теста, конечно.

Заключение

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

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

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

Серия статей про собеседования:
1. Я прочитал 80 резюме, у меня есть вопросы.
2. Наш первый обед вместе: почему и как мы проводим тестовый день.
3. Собеседование в Додо Пиццу.
4. Уходя уходи: почему не стоит принимать контроффер.

Я разрабатываю приложения для айфонов, но ещё провожу технический этап собеседования для iOS-разработчиков.

Раньше я проводил собеседование по стандартной схеме:

• слушал рассказ кандидата о себе;
• задавал вопросы;
• рассказывал о следующем этапе собеседования;
• договаривался о времени ответа и мы прощались.

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

Почему я решил давать фидбек сразу

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

Сейчас я провожу собеседование так:

1. Рассказываю о структуре собеседования. Буквально то, что вы сейчас читаете.
2. Рассказываю кратко про наш проект, его интересные стороны и будущие вызовы, про команду. Отвечаю на вопросы, которые могут появиться.
3. Кандидат рассказывает про свой опыт, а я попутно записываю вопросы. Спрашиваю всё в конце, чтобы не перебивать.
4. Если какую-то тему не обсудили, то спрашиваю точечно. Чтобы ничего не забыть, беру с собой на встречу чеклист из тем и вопросов.
5. Часто к концу встречи у кандидата снова появляются вопросы. Отвечаю на них.
6. В конце даю фидбек: принимаю решение на своём этапе технического собеседования и рассказываю о нём.
7. Раньше я думал, что на шестом этапе собеседование заканчивается, но у меня раз за разом происходила магия: после фидбека (неважно, положительного или отрицательного) кандидаты преображались, рассказывали необычные детали о себе и своём опыте, раскрывались с новой стороны.

Стоит отметить, что собеседование со мной не последний этап найма, потом может быть тестовый день и встреча с РО/CTO. Но результаты технического этапа вполне можно обсудить сразу вместе с кандидатом.

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

Инструменты и последствия моментального фидбека

До фидбека

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

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

На собеседовании мне важно выяснить, если ли у кандидата все необходимые технические навыки. Значит, все вопросы должны эти навыки раскрывать.

Чеклист вопросов и тем, чтобы ничего не забыть. Не пропустить какую-то тему мне помогает чеклист. Обычно процентов 60% из него кандидат рассказывает сам. Задавая дополнительные вопросы, стараюсь отталкиваться от рассказа самого человека, чтобы быть в мире собеседника, он там лучше разбирается. Получается нормальное общение.

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

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

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

Во время фидбека

Для ответа нужно время подумать пару минут. Сходу (экспромтом) выдать идеальный ответ не получится. Попросите у кандидата паузу в пару минут, пройдитесь по записям, посмотрите, как они сходятся в стройный ответ. Если чего-то не хватило, то можно доспросить.

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

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

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

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

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

После фидбека

Кандидаты удивляются моментальному ответу. У всего рынка есть привычка брать паузу в несколько дней, прежде чем дать ответ. Люди ожидают этого и от вас. Моментальный ответ даёт вам небольшой кредит доверия в глазах соискателя. Иногда разница с ожиданиями настолько сильна, что это пробивает кандидата на другой уровень общения, ломается официальность и атмосфера экзамена. Например, не все могут в обычном интервью сказать: Я никогда не писал тесты, но очень хочу прокачаться, научите. А после моментального фидбека могут. Из этого может получиться тема для тестового дня или задания.

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

Чтобы сильно не накопить ошибку к концу собеседования, я при обсуждении говорю о том, что услышал из рассказа: Ты сказал вот так, значит вот это? Нет, ага, а как?. Суммарная ошибка уменьшается.

Вы можете ошибиться ОЧЕНЬ сильно. Со мной такое было один раз. Во время фидбека я рассказал, что в ряде технологий кандидат разбирается слабо, а для нас они очень критичны. Он возразил, что про это я даже не особо спрашивал. Я опешил, это казалось полным провалом.

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

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

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

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

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

Обратный вывод: если вас не взяли в компанию Х, то просто вы не подошли ей. Такое бывает и с сильными разработчиками: специалист по 3D-графике может плохо работать с базами данных и UI-тестами, но отлично справляться с задачами в другом месте.

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

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

Итоги и выводы

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

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

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

Если в вашей компании открытость и честность это часть культуры, то почему бы не начать прямо на интервью?

Свои мысли и идеи о мобильной разработке я пишу в телеграм-канале Dodo Pizza Mobile. А ещё у нас открыто две вакансии в мобильном направлении. Так что я просто оставлю это здесь: iOS-developer (Нижний Новгород), Android-developer (Нижний Новгород).

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

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

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

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

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

Вы сейчас, наверное, подумали: ну, раз у них UX и UI-дизайны уже готовы, да еще и про запас часы заложены, то, наверное, всё должно пройти нормально? В большинстве случаев при установке сроков условия бывают похуже. Ну, в общем, нет. Нормально ничего не прошло.
Продолжительность работ была установлена в три-четыре недели не слишком много времени, если говорить о релизе нового продукта силами небольшой команды. Само собой, после первых двух недель мы уже стали отставать от графика. Не потому что медленно работали или мало часов тратили на проект, а потому что всё всегда идёт не по плану.

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

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

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

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

В обновлении не было ничего такого уж важного, что бы мотивировало необходимость релиза именно в эту дату и ни днём позже. Никто из пользователей не знал про то, что готовится новая версия, никто (ни клиенты, ни инвесторы) не строил планов с опорой на дату. Да, функции полезные, но разве кому-то стало бы хуже, если бы их выпустили на один день позже? Разве это вообще на ком-нибудь сказалось бы?

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

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

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

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

По моим прикидкам (статистику я не собирал, так что ручаться не могу), толк от этой переработки был только в краткосрочной перспективе. Ну да, выпустили приложение в срок. А следующий релиз уже пришлось задерживать, потому что многое переписывали. Разработчики были недовольны (и, как вы уже догадались, активно увольнялись), атмосфера в команде стала напряженной. И это мы еще не учитываем последствия багов, с которыми пользователи столкнулись после релиза.

Как нужно?

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

Всё сделали раньше срока? Ну, в такой ситуации все только выигрывают. И тестирование можно провести как следует, и дать разработчикам возможность что-то улучшить в кодовой базе. Если вы разработчик или общаетесь с разработчиками по работе, то сами знаете: в коде всегда есть места, которые хотелось бы подтянуть. Иногда это всего час и займет, а иногда речь идет о нескольких днях. Лучше не экономить время на том, чтобы сделать код лучше и аккуратнее как мы все можем подтвердить, в приложениях и так хватает недочетов, которые никто из пользователей не оценит.