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

RT @nat_davydova: Я из интереса веду статистику. Беру задачу и сама себе фиксирую, за сколько, на мой взгляд, я ее сделаю в часах. Потом т….

В тему оценки. Сейчас взяла в работу задачу по починке скриншотных тестов. Ситуация: локально и в ci тесты проходят с разным результатом. Докер образ один и тот же. Честно говоря, я пока что вообще не е*у что с этим делать. Как вы думаете, как мне оценить сроки на фикс? :).

RT @RobertMSterling: I'm sorry but someone had to do it

RT @bormatograf: Влюбился в обоих

RT @DragorWW: Забавно как разработчики приходят к открытию когда используют AI, что spec-driven development единственное что работает хорош….

Я же говорила, что обожаю твиттер?).

Если вы разработчик и от вас требуют сроки - попробуйте так и сказать: “Я точно успею сделать вот это, остальное - постараюсь, если не вылезем за дедлайн”. Тогда вы сможете рассчитывать на то, что критическая функциональность будет готова в срок, а опциональной можно пренебречь.

Я сделала каркас фичи за неделю, но не успела добавить ряд фич в свое решение, плюс пропустила некоторые корнер кейсы. Менеджер осталась довольна. А затем попросила доработать решение и учесть корнер кейс. “Хорошо,” - сказала я, - “на это мне нужна еще неделя”. На том и порешили.

Первый раз я применила этот способ еще в 2019 году. Я прикинула, что мне нужно около двух недель на задачу. Однако менеджер вернулась ко мне со словами - “бизнес не дал тебе две недели, бизнес дал тебе неделю”. “Хорошо, я могу сшить семь шапок из этой шкурки,” - подумала я.

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

Однако можно сделать ровно противоположное: не угадывать срок, который уйдет на разработку, а зафиксировать время, которое вы готовы уделить на фичу. Например: “Мы готовы потратить на эту фичу 2–5 дней. Обязательно - чтобы работало вот это. Всё остальное сделаем по возможности”.

Алан Тьюринг доказал неразрешимость этой проблемы еще 90 лет назад, однако менеджеры по сей день продолжают пытать программистов на очередном дейли вопросом “так, с��олько тебе еще делать эту задачу?”.

Разработка - это сборка конструктора из мелких деталей: никогда не знаешь, подойдёт ли новая деталь к уже собранной части. Это напоминает проблему остановки Тьюринга: для любых двух функций F и G мы не можем определить, что их суперпозиция остановится (= заработает как надо).

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

В защиту программистов скажу, что проблема оценок существует не только в айти: любой сложный процесс практически невозможно спрогнозировать. Один мой менеджер как-то сказал: представь, что твой врач не может назвать, сколько времени уйдет на лечение, что ты будешь чувствовать?.

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

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

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

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

Почему у меня все наоборот????.