Чужие задачи

Мы всегда недооцениваем время выполнения чужих задач.

“Да что там делать-то! Ерунда!”

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

Мои любимые заявления:

  • Это делается за 10 минут
  • Ставится за одну команду
  • Там нужно просто …

Как говорит Владимир Романичев, когда задачу в работу взяли и приходишь с вопросом “ну шо?”, то звучит следующий популярный набор фраз:

  • Оно почти работает
  • Оно работает, но вот это не работает
  • У меня всё работает

Добавлю от себя:

  • Почти доделал, проверить осталось
  • На 80% готово
  • Завтра точно будет

Почему так происходит?

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

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

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

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

Сколько нужно времени, чтобы сварить яйцо?

Если вы подумали “яйцо варится 12 минут, значит 12 минут”, то это неправильный ответ.

Представьте, что вы находитесь у себя дома и попросили друга сварить яйцо. Друг согласился, и вы запустили таймер.

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

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

Это тоже занимает время, но почему об этом не подумали в начале?

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

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

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

Всё это увеличит время на выполнение задачи.

Не говоря уже о рисках:

  • Отключили воду
  • Сломалась плита
  • В районе вырубили свет и кассы в магазине не работают

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

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

История про интеграцию Tilda и Iiko

Задачи часто не выглядит сложными — пока не начнёшь их делать.

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

Заказ на интеграцию.

История из личного опыта.

Вот мы взяли заказ. Интеграция Tilda (конструктор лендингов) и Iiko (система управления ресторанами, кафе).

Лендинг ресторана на Тильде. На лендинге форма бронирования. Нужно сделать чтобы при отправке формы данные попадали в Iiko.

От Тильды приходит вебхук со всеми данными с формы, в Iiko есть API в котором можно создавать бронирования.

Оценим сроки?

Я изначально оценил в пару дней. И назвал срок неделю.

А теперь реальный опыт.

Часть первая, доступы в API.

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

Несколько дней на изучение того что есть на сайте плюс чуть экспериментов с Тильдой и Iiko.

Выясняется что доступ к Iiko нерабочий, точнее часть их апишки в нерабочем состоянии.

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

Далее переписка с ними. Одно что-то починили.

Беру это и копаю апишку дальше, ещё что-то не работает.

Опять отправляем всю инфу, ждём пока починят, дни, неделю.

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

Отвечаем что это всё не подходит. Опять ждём.

Откопали причину, перезагрузили какой-то сервер и заработало. Починили.

Далее апишка заработала и можно заниматься непосредственно интеграцией.

Часть вторая, погружаемся в разработку, ищем решение.

Пишем код.

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

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

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

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

Если заполнять обязательные поля значениями по умолчанию то будет вводить в заблуждение.

Решение — сделать промежуточную панель с заказами, в которую будет падать заказ с Тильды, дозаполняться менеджером который перезванивает посетителю, и вбивает детали в заказ и далее кнопкой отправляет это в Iiko.

Предлагаем это заказчику, ждём согласования на его стороне.

Часть третья, реализуем решение.

Заказчик согласовал, ещё недельку пилим эту панель, учитывая все нюансы и Тильды и Iiko.

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

Столиков много и с остальными полями в форму они не помещаются.

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

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

Итоги

На всё про всё ушёл месяц.

Вот и оценивай после этого…

Два дня? Ну да. В идеальном мире!