Привет! Если ты сейчас учишься программировать, и думаешь что‑то вроде «Вот выучу все, и тогда пойду на собесы», то у меня для тебя плохая новость — выучить все невозможно. Это осознание пришло ко мне только спустя несколько лет работы backend разработчиком.
В этой статья я расскажу
Почему даже синьоры постоянно что‑то учат
Как в IT оценить сроки задач и при чем тут Toyota
И на каком языке написаны программы, обрабатывающие 90% банковских транзакций в мире.
Погнали!
Без чего невозможно программировать?
Представь, что ты решил стать программистом на Java. Ты хочешь понять, что нужно знать, чтобы устроиться на первую работу. Конечно сам язык, но что еще? Если у тебя нет знакомых айтишников, которые могут подсказать, ты, скорее всего, зайдёшь на сайт вакансий, чтобы проверить свои догадки.
В вакансиях ты увидишь слова вроде Maven, Gradle, JDBC, SQL, Postgres, REST API, Spring, Kafka, Kubernetes и ещё много других загадочных терминов.
Теперь ты можешь закрыть ноутбук и пойти работать курьером, там как раз подняли зарплаты.
А че так сложно то?
Проблема в том, что даже в одной области программирования существует слишком много инструментов. Знать их все досконально невозможно. Чтобы найти человека, который идеально знаком с вашим стеком, вам нужно... нанять того, кто уволился из вашей команды год назад. Но даже он успел многое забыть, ведь все это время использовал совсем другие инструменты: вместо Kafka — RabbitMQ, вместо Postgres — MongoDB, а вместо Kubernetes — OpenShift.
Вот почему глубоко разбираться в какой‑то конкретной технологии зачастую бессмысленно. Достаточно иметь общее представление обо всём, чтобы понимать, о чём идёт речь. Для этого даже придумали красивый термин: T‑shaped специалист.
Такой человек хорошо разбирается в чем‑то одном, и имеет представление о смежных областях. Сейчас от разработчика ждут не только написание кода, но и работу с ci/cd, тестирование, поддержка сервиса в проде, эффективную коммуникацию с командой, а иногда и с бизнесом.
Но даже если ты решишь стать экспертом именно в том, что используется у тебя на проекте, скорее всего у тебя не получится. Потому что у бизнеса всегда одна просьба: “Сделайте фичу вчера”. Поэтому ты сначала релизишь, и только потом начинаешь разбираться, что вообще сделал и почему это работает.
Есть одна вещь, без которой невозможно программировать (помимо компьютера конечно), — это интернет. Отключи программисту доступ в сеть — и с вероятностью 90% он не напишет даже простое веб-приложение. Тем более полноценный большой сервис. И это нормально, держать в голове все необходимое практически невозможно. Главное - способность найти нужную информацию и разобраться в ней настолько, чтобы выполнить задачу в установленные сроки.
А как установить сроки?
Хорошо, программисты не знаю все технологии, которые используют, но опытные разработчики наверняка умеют оценивать, сколько займёт та или иная задача? Ведь да?
К сожалению, нет.
Если бы существовал мир, где программисты могут точно оценивать сроки, мы бы уже жили в утопии с летающими автомобилями и полностью автономными городами. Но реальность далека от этой фантазии.
Программисты хитрые, они не говорят "Мы не знаем, когда сделаем задачу", они говорят "AGILE". Существует два распространенных подхода к оценке задач в условиях неопределенности.
Первый вариант - Story points
Стори-поинты - это буквально оценка задачи в попугаях. Оценивать в часах бессмысленно, поэтому программисты придумали абстрактные стори-поинты.
Берем самую простую задачу которая есть на проекте и говорим - она занимает один стори-поинт.
Все остальные задачи оцениваем относительно этой - 2, 4, 10 стори-поинтов. Оценивать кстати - тоже непросто, для этого есь отдельный ритуал - planing poker, об этом можно почитать тут - https://ru.wikipedia.org/wiki/Покер_планирования.
Теперь ждем какое-то время и смотрим, сколько в среднем стори-поинтов за спринт выполняет команда.
Накидываем на это понижающий коэффициент, чтобы заложить риски
PROFIT - теперь мы знаем сколько стори поинтов может сделать команда за спринт.
Правда это число со временем постоянно меняется, но лучше чем ничего
В одной команде 1 стори-пойнт может быть примерно равен часу работы, а в другой — неделе. Вот что имеем в итоге:
Никто все еще не знает, сколько точно времени займёт задача.
Мы выглядим профессионально, ведь вместо “да хрен его знает” мы говорим: “это задача на 3 стори-пойнта”.
Второй вариант - kanban
Эта практика честно украдена c производства Toyota. Правда там это были физические бумажки на доске, а у нас тикеты в Jira, но сути это не меняет. Давай разберемся как оценить сроки задач с помощью канбана.
Задаем несколько статусов, например - To Do, In Progress, Review, Testing, Done
Ждем какое-то время, и замеряем сколько занимает переход задач из статуса To Do в статус Done
Теперь совершается магия - например 95% задач проходят этот путь за 10 дней. Теперь мы можем говорить бизнесу что задачу, с вероятностью 95% будет готова через 10 дней.
-
Есть конечно, нюанс, что с вероятностью 1% она будет готова через год, но зачем забивать бизнесу голову какими-то нюансами.
Хорошо, программисты не знают сколько займет задача, но они ведь знают как работают их системы? Да?
Не совсем...
ТОП-1 язык программирования в 2025 году
Небольшое отступление от темы - мы уже выяснили, что технологий существует множество, включая языки программирования. Java, Python, JavaScript, Go, C++ — как выбрать самый важный?
Без какого языка нельзя представить современный мир?
Внезапный ответ: самый важный язык — это COBOL, созданный в 1959 году.
Почему COBOL до сих пор актуален?
На COBOL работают программы, которые обрабатывают 80–90% банковских транзакций в мире. Это все, конечно, круто, но язык выглядит устаревшим и неудобным по сравнению с современными.
IDENTIFICATION DIVISION.
PROGRAM-ID. HelloWorld.
ENVIRONMENT DIVISION.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 WS-USER-NAME PIC A(30). *> Переменная для хранения имени пользователя
PROCEDURE DIVISION.
DISPLAY "Введите ваше имя: " *> Печатает сообщение в консоль
ACCEPT WS-USER-NAME *> Принимает ввод от пользователя
DISPLAY "Привет, " WS-USER-NAME "!" *> Выводит приветствие с именем
STOP RUN. *> Завершает выполнение программыПочему тогда его не заменяют? Всё просто. Многие системы на COBOL работают десятилетиями. Их переписывание потребовало бы огромных затрат времени и денег, а также несёт риск полного краха, потому что:
Эти системы настолько сложны, что вряд ли кто-то понимает все детали их работы полностью.
Документация редко бывает актуальной.
Те, кто создавал систему, давно ушли из компании (или из программирования).
Современные программные продукты настолько сложны, что не помещаются в голове одного человека. Мы все вынуждены работать с тем, что есть, ведь несмотря на сложность, такие "костыли" как COBOL продолжают использоваться, потому что альтернативы требуют гораздо большего времени и ресурсов.
...несколько лет назад Commonwealth Bank of Australia попробовал переписать ядро системы на новом языке. Переход состоялся, но на проект ушло около 1 млрд австралийских долларов — это в несколько раз больше, чем планировалось.
Итоги и советы
Никто не знает сколько времени займет задача, никто не знает все технологии, которые могут пригодиться при реализации очередного сервиса, никто не знает как переписать старую, сложную программу на современный язык.
Именно поэтому программирование стало командной работой. Поэтому часто отдают предпочтение кандидатам по soft скилам, и поэтому тебе не нужно знать все.
Главные навыки - способность быстро учиться новому и эффективно взаимодействовать с командой.
Если чего-то не знаешь - это нормально, спроси.
Если не успеваешь к срокам, о которых договорились, это нормально, главное скажи об этом как можно раньше, и подсвети что не учли при оценке.
А если ты только в поисках первой работы, не пробуй выучить все, иди на собеседование, возможно ты уже знаешь достаточно.
Комментарии (51)
gun_dose
04.12.2024 12:30Оценивать в часах бессмысленно
Чушь полная. Все ваши сторипоинты потом всё равно сконвертируются в часы, потому что каждый сотрудник работает 40 часов в неделю, и никак иначе. Понятно, что каждый сотрудник может выполнить разный объём работы за эти 40 часов, но поэтому у сотрудников бывает разная почасовая ставка. Игнорировать тот факт, что бухгалтерия в расчётах оперирует часами, это то же самое, что заметание мусора под ковёр. ПМ снимает с себя головную боль в виде подсчёта капасити команды, а в конце года бухгалтер поднимает ковёр, а что у нас под ковром? Правильно - под ковром у нас кассовый разрыв.
Ждем какое-то время, и замеряем сколько занимает переход задач из статуса To Do в статус Done
Ээээээ, серьёзно? Это же получится средняя температура по больнице. Одна задача - перекрасить кнопку, вторая задача сверстать целую форму. В итоге форму верстали два дня, а кнопку красили три недели, потому что QA был в отпуске.
dsvdev Автор
04.12.2024 12:30Ээээээ, серьёзно? Это же получится средняя температура по больнице. Одна задача - перекрасить кнопку, вторая задача сверстать целую форму. В итоге форму верстали два дня, а кнопку красили три недели, потому что QA был в отпуске.
Именно из-за того что форму верстают два дня а кнопку красят три недели - единственный хоть как-то работающий способ "средняя температура по больнице"
gun_dose
04.12.2024 12:30Единственный работающий способ - это когда ПМ спрашивает разработчика, сколько ему потребуется на такую задачу, потом докинуть время на QA и поправку на непредвиденные обстоятельства. Затем разраб должен внести время, реально затраченное на задачу (автоматическим тайм-трекером или вручную - неважно), QA должен внести своё время. В конце спринта, даже если QA был в отпуске, ПМ должен посмотреть, сколько затраченного времени внесено в задачу и сравнить это с первоначально выставленной оценкой. Если затраченное время сильно расходится, ПМ должен всё зафиксировать где-то у себя, и учитывать при последующих планированиях. На самом деле, это немного похоже на то, что вы сказали, но замерять надо не время от ToDo до Done, а соотношение реально затраченного времени к оценке.
dsvdev Автор
04.12.2024 12:30Согласен, тут логичнее не от ToDo, а от InProgress
Я описал два подхода:
1. Мы сравниваем реально затраченной время с оценкой в сторипоинтах, и постепенно начинаем понимать сколько в данной конкретной команде часов занимает один сторипоинт.
2. Мы просто замеряем затраченной время на задачи, без первоначальной оценки, собираем статистику по перцентилям, и на основе этого делаем прогнозы по следующим задачам.
По крайней мере, я на практике встречался с этими двумя подходами, и они работали достаточно точно.
Но наверняка есть и другие варианты, тут мне спорить не с чемgun_dose
04.12.2024 12:30В итоге всё всегда сводится к тому, чтобы по результатам ретроспективы корректировать оценку производительности сотрудников.
piton_nsk
04.12.2024 12:30постепенно начинаем понимать сколько в данной конкретной команде часов занимает один сторипоинт
Зачем нужна оценка в сторипойнтах, если в реальности все равно существует явный или неявный перевод из сторипойнтов в часы? И в итоге все равно все сводится к часам.
Nalivai
04.12.2024 12:30Скорость выполнения в часах зависит от человека/команды, а сторипоинт дает гранулярность того насколько задача простая для всей фирмы условно говоря.
"Фигня, но не прям фигня, посложнее чем прям фигня, но все еще фигня, легче чем охренеть" и всякое такое, превращается в три сторипоинта, и это позволяет, зная среднюю скорость в сторипоинтах в месяц, абстрактно задач напихать в бэклог "типа чтобы до конца года хватило плюс-минус", а потом когда до каждой дело доходит, уже идет "ну A такое сделает за два часа, но у него завал, а B закопается на целый день, но ему делать нечего, поэтому ему поручим, и срок будет два дня"
R3B3LL10N
04.12.2024 12:30Был у нас разговор с аналитиками буквально на той неделе... я им про часы, а они мне - один про футболки, второй про сторипоинты. Мол, в часах оценить невозможно. Зато вот футболка XXL и 10 поинтов - это большааая задача. И можно прикинуть что она стоит примерно... 40 часов.
Я им - так получается всё равно к часам возвращаемся? Ну да... но нет... но да...
Короче, это всё равно что спорить в чём мерить длинну - в футах или в метрах. Где как принято, там так и мерят. Хуже всего получается когда у одних фут британский (~0.3м), у других бразильский (~0.33м), а у последних римский (0.25м). Потому-что ноги у всех разные, как и размеры футболок или, прости господи, стори поинтов.
К чему я? Да к тому что есть универсальная, а главное, точная единица - часы. Точнее неё вам ни поинты, ни футы, ни футболки, ни любая другая абстрактная единица не оценит задачу.
powerman
04.12.2024 12:30Да, всё-равно возвращаемся к часам. Но, нет, это другое. :-)
Фишка в том, что оценка в сторипоинтах универсальна для всех разработчиков, потому что описывает относительную сложность задачи - относительно другой, минимальной, задачи. А вот оценка в часах для разных разработчиков для одной и той же задачи может очень сильно отличаться - в зависимости от кучи факторов, начиная от джун/сениор и заканчивая тем знаком ли конкретный разработчик с данным типом задач и насколько конкретно этот разработчик любит затягивать задачи делая разные посторонние штуки (напр. пытаясь сделать более гибкое/универсальное/красивое решение чем реально необходимо).
Поэтому переводить в часы имеет смысл когда уже понятно кто именно из команды будет делать эту конкретную задачу. И если задача передаётся от одного разработчика другому то оценку в часах нужно корректировать. И это ещё простой случай, потому что если обсуждаемая задача не является низкоуровневой микротаской для разработчиков а является более высокоуровневой бизнес-задачей, над которой по определению должны работать несколько разных людей (дизайнер, разработчик, тестировщик), то такую в часы конкретного разработчика в принципе переводить бессмысленно, и можно только статистически через какое-то время выяснить среднее отношение между сторипоинтами и человеко-часами (а, скорее, человеко-неделями).
Поэтому и получается так, что "перевести в часы" - можно, а сразу назвать "в часах" - нет.
click0
04.12.2024 12:30Это в случае одной задачи.
А когда разработчик делает несколько задач - все становится сложно и малопредсказуемо по срокам.gun_dose
04.12.2024 12:30Почему это? Большие задачи потому и делят на много маленьких, потому что оценка маленьких задач всегда будет точнее.
по срокам
Прогнозировать надо не срок выполнения задачи, а время, которое будет затрачено на её выполнение. Нельзя говорить "я сделаю эту задачу к четвергу", нужно говорить "я сделаю эту задачу за 10 часов". Есть другие срочные проекты - всегда пожалуйста. Пусть задача будет готова даже через год, но если за этот год на неё будет потрачено всего лишь 10 часов, значит оценка была дана верно.
Kergan88
04.12.2024 12:30>Большие задачи потому и делят на много маленьких, потому что оценка маленьких задач всегда будет точнее
Не поэтому, на самом деле, это лишь распространенное заблуждение. На самом деле все точно наоборот - чем меньше задача, тем менее точной будет оценка, в силу того что риски не усредняются.
powerman
04.12.2024 12:30Оценка такой мелкой таски будет тем точнее, чем меньше таска. Так что это не совсем заблуждение. Риски не усредняются, да, но и сами риски по мелким таскам тоже мелкие, и даже срыв сроков по мелкой таске в разы почти никак не скажется на общем прогрессе проекта, ведь такое будет происходить с небольшим процентом задач.
Тут есть немного другой аспект: после декомпозиции может быть сложнее оценивать время, которое требуется на то, чтобы из кучи мелких задач собрать крупную бизнес-фичу. Потому что да, там появляются дополнительные риски, которые в мелкие задачи не заложены - начиная от того, что в процессе работы требования могут изменяться и это может приводить к тому что количество мелких задач вырастет раза в 2-3, и заканчивая тем, что в этих мелких задачах редко закладывают риски связанные с интеграцией/прохождением ревью безопасников/ожиданием дизайнера или тестировщика и т.п. Тем не менее, это всё решаемые проблемы - как отдельной оценкой крупной бизнес-таски традиционными способами так и налаживанием процессов которые будут минимизировать упомянутые риски.
Wesha
04.12.2024 12:30оценка маленьких задач всегда будет точнее
...вот только непонятно будет — придётся ли эту маленькую задачу делать, или мы решили пойти другим путём.
Mox
04.12.2024 12:30Сторипоинты - это оценка сложности, и бывает так что задачу на много стрипоинтов удается решить за пол дня, только потом пол дня все равно уже ничего сделать не получится.
Поэтому и оценивают количество сложности, котрое переваривает команда в неделю, и это позволяет достаточно точно строить поаны и анализировать.
В часах оценка плоха тем, что всегда есть куча активности, которая двигает процесс в целом - например - ответить на вопрос коллеги, но к конкретной задаче не относится. Короче я не видел чтобы хоть раз оценка в часах нормально работала и не приводила к бесплатным овертаймам или вопросам - а почему на это ушло столько часов
gun_dose
04.12.2024 12:30Я уже четвёртый год работаю без каких-либо овертаймов, при этом всё измеряем в часах. Чтобы оценка нормально работала, всегда нужен запас. Если я даю оценку три часа, значит я справлюсь за три часа, но проджект всё равно ставит 5.
ответить на вопрос коллеги
Если вопрос очень объёмный, нужно залогировать потраченное время в задачу коллеги. Ну или спросить у проджекта, куда его логировать.
а почему на это ушло столько часов
В случае непредвиденных сложностей нужно сообщать проджекту, как только эти сложности появляются. Плюс нужно собрать всю информацию, которая поможет клиенту понять, что проблема действительно непредвиденная: ссылки на спецификации, issue к библиотекам, скрины с пояснениями и т.д.
Поэтому и оценивают количество сложности, котрое переваривает команда в неделю
В часах это ещё проще: количество людей умножаешь на 40. На самом деле сторипоинт - это человекочас, умноженный на производительность сотрудника. Условно, 1 сторипоинт = 1 час мидла = 2 часа джуна = 30 минут сеньора. Но в таких единицах есть необходимость только когда у членов команды сильно разная производительность и непонятно, кто какую задачу будет делать. Если же в команде до 10 человек и проджект хорошо знает каждого разработчика, то можно смело оценивать в часах, зная наперёд, кто именно будет делать эту задачу.
Drucocu
04.12.2024 12:30Я уже четвёртый год работаю
А я 12 лет. Вы специфику работы указывайте хотя бы, когда своими рассужденимяи делитесь. Так сказать, граничные условия, в которых это всё работает. Вы 1С-франчайзи, веб-студия, работающая с CMS, или другого сорта галера, в которой все задачи идентичные и вы делаете одно и то же годами для разных заказчиков? Да, для вас такая схема подходит.
Для продуктовой же разработки, когда каждый спринт придумываются фичи, которых внутри данного продукта ещё не было, ваши рассуждения не применимы.
gun_dose
04.12.2024 12:3012 лет
А мне почти 40. Ловко я цифру из контекста выловил, да? У вас приёмчик подсмотрел. "Четвёртый год работаю без овертаймов", но перед этим ещё 5 с периодическими овертаймами и ещё 8 вне IT.
заставить разработчика постоянно испытывать стресс за "неверно выставленные сроки"
Я такого нигде не предлагал, вы сами это выдумали. Сроки - это проблема только менеджмента. Я пишу о том, что менеджмент должен советоваться с разработчиками о сроках, но советоваться - это не значит перекладывать ответственность.
Специфика, если вам интересно: годами делаю разные задачи для одного заказчика.
Drucocu
04.12.2024 12:30Ловко я цифру из контекста выловил, да?
Я не собирался вырывать из контекста. Ваш комментарий в моём представлении соответствует тому, что может написать человек с 4-мя годами опыта на одном месте. Но тот факт, что вам ближе к 40, также объясняет вашу категоричность.
Вы рассуждаете, будто видели всю разработку изнутри, но создаётся впечатление, что вы работали всё время в одной и той же компании, и не видели других способов организации работы. Например, в этом комментарии вы говорите, что работаете в веб-студии. Кстати, это всё-таки означает, что вы работаете с разными заказчиками.
gun_dose
04.12.2024 12:30Ссылка на комментарий некликабельная, не могу понять, о каком комментарии идёт речь. Я занимаюсь веб-разработкой, но не работаю в веб-студии. Я работаю в аутсорсинговой компании и в последние два с половиной года я работаю только на двух проектах для одного клиента. Хотя вам, конечно, виднее.
Drucocu
04.12.2024 12:30годами делаю разные задачи для одного заказчика.
Я работаю в аутсорсинговой компании и в последние два с половиной года я работаю только на двух проектах для одного клиента.
Во-первых, это подтверждает моё предположение о том, что вы работаете в аутсорсе, отсюда ваша необходимость логировать время и отчитываться за каждый час. Как я писал выше, к счастью, далеко не все мы вынуждены работать таким образом, поэтому ваши рассуждения применимы только для ваших коллег-аутсорсеров.
Во-вторых, не могу не обратить внимание на то, что во всех ваших комментах разный опыт работы в той или иной роли, поэтому боюсь, ваш реальный опыт не ясен не только мне, но и всем читающим.
PS ссылку проверил, рабочая.
gun_dose
04.12.2024 12:30Не знаю, что именно вы хотите мне доказать, но пока что я вижу только то, что вы не понимаете разницу между веб-разработкой и веб-студией и на основании этого заблуждения зачем-то пытаетесь делать какие-то выводы обо мне лично.
PS ссылку проверил, рабочая.
Ссылка заработала после того, как вы отредактировали свой комментарий.
Вот эту цитату из вашего комментария:
Например, в этом комментарии вы говорите, что работаете в веб-студии
я специально оставлю здесь, на случай если вы опять отредактируете и будете говорить, что имели в виду другое.
Drucocu
04.12.2024 12:30Так я действительно не понимаю. Уж простите, но для меня любое место, где надо логировать время - это галера. Я в таком работал в начале карьеры, но искренне надеюсь, что больше в такие условия не попаду. Зарекаться, конечно, не стоит, поэтому я говорю, что надеюсь.
И вы виляете, как уж, прикапываясь к формулировкам, лишь бы уйти от основной мысли, которую я хочу до вас донести: не все тут работают как вы. Поэтому ваши рассуждения неиприменимы ко всей отрасли.
К этой мысли есть претензии? Может, я некорректно использовал слово "отрасль", а следовало использовать "профессиональное сообщество", например?
gun_dose
04.12.2024 12:30Вы настолько неумело жонглируете терминами, что от меня ускользает мысль, которую вы хотите сказать.
Веб-студия - это маленькая организация, которая занимается созданием простых сайтов под ключ. Там проекты уровня "бюджет 1000$ и срок месяц". Один проект там как правило делает один программист, поэтому командной работы как таковой нет, а управление проектами крайне примитивное. Вы почему-то сделали выводы, что я работаю именно в веб-студии, хотя в моём комментарии, приведённом вами же по ссылке, я называю порядок стоимости обслуживания проекта, на котором работаю и такой бюджет несовместим с понятием веб-студии.
Галера на айтишном жаргоне - это крупная аутсорс-компания. И вы очень зря пренебрежительно относитесь к ним, потому что в любой галере проджект-менеджмент априори должен работать лучше, чем в продуктовой компании. Если галера зафакапит сроки, их клиент просто наймёт другую галеру. Если же продуктовая компания зафакапит сроки, то просто перенесут релиз на попозже.
Что касается сложности проектов и квалификации разработчиков, то нет никакой разницы между продуктом и аутсорсом. Во-первых, многие продуктовые компании отдают отдельные фичи на аутсорс. Во-вторых, аутсорс-компании могут работать с проектами, которые крупнее и сложнее многих продуктов. В-третьих, есть небольшие продуктовые компании, в которых вообще нет своих разработчиков.
Поэтому ваши рассуждения неиприменимы ко всей отрасли
Уметь правильно оценивать задачи в часах - это очень сложно, и многие не могут этому научиться. Естественно, мои суждения неприменимы там, где не умеют оценивать задачи, и это очень большой кусок отрасли. И меня в целом очень расстраивает, что вместо того, чтобы признать важность и сложность проблемы, происходит инфантилизация IT-сообщества и придумываются всякие детсадовские понятия вроде сторипоинтов
Drucocu
04.12.2024 12:30Ну вот вы и изложили по пунктам ваше пренебрежительное отношение ко всем, кто посмел работать не так, как вы, а также раздутое самомнение, которое я заподозрил у вас с самого начала.
придумываются всякие детсадовские понятия вроде сторипоинтов
Да-да, мы в своих фаангах детсадом занимаемся, а вот на галерах люди действительно знают, как надо работать. /s
Я, конечно, не преуменьшаю того факта, что вы, вероятно, работаете на износ и гораздо интенсивнее меня. Но мне всё-таки не кажется разумным распространять на всех формат, где "мерилом работы считают усталость".
Как я говорил выше, я поработал и в таких условиях, как вы, и в детсаду со сторипоинтами. Как-то так получается, что в детсаду я выполняю гораздо более интересные и масштабные задачи, которые просто бесполезно оценивать в часах. Вы либо декомпозируете задачу на 40 штук, что само по себе бред, либо у вас будут оценки по 40 часов, что тоже не сильно информативно.
click0
04.12.2024 12:30как только эти сложности появляются. Плюс нужно собрать всю информацию, которая поможет клиенту понять, что проблема действительно непредвиденная: ссылки на спецификации, issue к библиотекам, скрины с пояснениями и т.д.
Тут иногда дополнительные часы появляются, куда их указывать?
gun_dose
04.12.2024 12:30В любом таск-менеджере есть описание к затраченному времени. Если потратил 10 часов вместо 2, пишешь 10 часов и в описание вот эту всю инфу.
click0
04.12.2024 12:30Так это же не на решение задачи, а на сбор сведений, что эту задачу не решить или появилась непредвиденная проблема .
Mox
04.12.2024 12:30Это совсем разные культуры. Cкорее всего - заказная разработка или продукт.
В продуктовой - нет смысла тратить время на подсчет часов и не надо ничего выставлять.
У нас, например, попусту нет проджектов (масштаб продукта - человек 50). Есть продакты, они определяют продуктовые гипотезы и бэклог. Но можно прикинуть сколько экономии ФОТ идет.
- Помогают ли сторипоинты планировать - да, конечно. Можем ли мы деливирить к дэдлайну - конечно.
Зато если разработчик понимает что фичу можно реализовать дешевле в общем он спокойно идет к дизайнеру, он обновляет макеты (и тратит может быть еще несолько часов) и все счастливы.
В история с оценками "до часов" такие коммуникации как правильно затруднены, а менеджеры не смотрят на общий оптимум трудозатрат, а только чтобы все было сделано по оценке. Ну и атмосфера как правило так себе в таких фирмах, со всей текучкой.gun_dose
04.12.2024 12:30Если у вас продакт занимается бэклогом, то это значит, что у вас есть проджект, просто вы его назвали продактом. Единственное отличие разработки в продуктовой компании от разработки в аутсорсе - это менее строгое планирование. Но всё очень отличается от случая к случаю. Например, в стартапах атмосфера и текучка, как правило ещё хуже, чем на аутсорсе, потому что им нужны "горящие глаза". Отличие продукта от стартапа весьма условное и всё сводится к тому, сколько ещё денег осталось у владельца. Как только финансовые показатели продукта приблизятся к критическим, сразу появятся и дедлайны, и планирование, и текучка.
Mox
04.12.2024 12:30Продакт является источником задач стратегического уровня. Понятно что декомпозиции и согласования уже делают команды.
Продакт следит за метриками продукта.
Проджект следит за сроками, фичами и бюджетом, также рисками. За метрики он вообще отвечать не может - потому что это не его ответственность, если фича не нужна юзерам, его задача - заделиверить фичу.Совсем разные роли.
Проджект может быть "прослойкой" между продактом и конкретной командой, но в целом не очень нужна если всего несколько команд по несколько человек, тем более - меньше прослоек - проще пересогласования, если хочется что-то упростить.
R3B3LL10N
04.12.2024 12:30Окей. Оценил задачу в один сторипоинт. Из за вопрос коллеги потратил, условно, два. Как это спасает по сравнению с часами?
Человек не воспринимает абстракции, которые не с чем сравнить. В астрономии, например, массу объектов мерят солнечной массой, а расстояния астрономическими единицами. Потому-что это точно посчитанные величины и легко построить аналогическую абстракцию. 10 солнечных масс - это дофига. 10 АЕ - тоже не мало.
Сторипоинты даже в одной компании на разных проектах скорее всего будут разные. Это привязка непонятно чего непонятно к чему и непонятно зачем. Даже в статье сказано что поинт привязывается ко времени затраченному на самую лёгкую задачу. А сведётся всё к одному - "Вася поставил 1 поинт, это примерно 1-2 часа". Зачем тогда все эти кручу-верчу запутать хочу?
rpc1
04.12.2024 12:30Сторипоинты - это все таки оценка сложности задачи, а не времени затраченной. Если условный Вася ставит сторипоинты и сам же собирается реализовывать эту задачу, то он способен оценить ее и в часах. Но когда в команде 5, 10 разработчиков, то у оценка в часах может отличаться. И опять 1 сторипоинт <> 2 часа, так как может быть простая задача, в которой надо кучу файлов править руками или тестов, т.е. ничего сложно, но занимает много времени, причем одинаково, что у синьора, что у джуна.
Drucocu
04.12.2024 12:30А теперь вынимаем голову из песка и вспоминаем, что далеко не все IT-компании организованы по принципу галер (к нашему общему счастью).
Поэтому рассуждения на тему, как заставить разработчика постоянно испытывать стресс за "неверно выставленные сроки" и выжимать из него все соки, пока не сдохнет, оставляем себе и в приличном обществе не показываем.
LoshadkaNaRabote
04.12.2024 12:30Поделюсь своим скромным опытом наблюдения за командой: рп, разраб, аналитик и куча еще всякого народа. На совещаниях человек по 6-7. По итогу, низкий КПД, команда год проедала деньги и всех разогнали. Это, конечно, частный случай и не дает нам практику, но за этот год они попробовали много схем борьбы с атомизацией, включенностью команды, дошли до того, что пол дня занимали совещания. Оплата стояла почасовка с учетом работы над задачей, но, пользуясь этой дырой (тем, что никто никогда не знает, сколько в реальности это займет времени) команда просто ела деньги заказчика.
dkfbm
04.12.2024 12:30Поднимают программиста из анабиоза. Открывает глаза, спрашивает: какой сейчас год? 9999... скоро 10000, а тебя с сиви написано, что знаешь кобол...
AndronNSK
04.12.2024 12:30Однажды биг босс мне пишет по поводу какой-то длинной противной бесконечной фичи - если, грит, я усну на 15 лет, а потом проснусь - ты всё ещё будешь делать эту штуку? Я ему - не, неделей раньше закончу.
dkfbm
04.12.2024 12:30если, грит, я усну на 15 лет, а потом проснусь - ты всё ещё будешь делать эту штуку?
Не, тут немного про другое – эта шутка ходила, когда с проблемой 2000 народ активно боролся.
vic_1
04.12.2024 12:30Когда то я ехал в поезде с профессором, он возмущался по поводу зарплат. Я спросил у него сколько книг по профессии он прочёл за последнее время, на что он ответил, зачем мне что то читать, если если ничего нового не было с начала прошлого века. Вот по этому и такая разница в зарплате, программист учится пока работает. Каждые 3-5 лет новая мулька, не сказать чтобы сильно новая, но все же поизучать придётся.
По поводу оценки времени, если задача хорошо декомпозирована на подзадачи, проблем с оценкой нет. Для декомпозиции необходимо провести исследование и потратить 1, 2 дня иногда побольше, но иначе никак
killyself
04.12.2024 12:30Встречал как минимум два класса задач, которые - мягко говоря - хреново декомпозируются:
1) Мы не знаем что конкретно надо сделать. Примерно что то такое, но подробностей мы не узнаем, делайте что нибудь. Тут до прототипа никакой декомпозиции не выйдет 100%, да и потом будет гадание на чаинках.
2) Задача чисто на исследование. Но невозможно оценить, сколько займёт исследование т.к задача нетривиальная. Максимум можно заложить какие-то часы, и по их результатам либо задача решится, либо не решится. Такие задачи встречаются не очень часто, но встречаются. И решаться они могут как за 2 часа, так и за 2 неделиpowerman
04.12.2024 12:301) Пока неизвестно что делать - делать ничего нет смысла. Но обычно известно, что нужно сделать прямо сейчас. Да, какой эта фича будет в финальном продукте - неизвестно, но ведь и делаем мы сейчас не финальный вариант, а текущий прототип. И вот на текущую задачу-прототип время оценивается как обычно, ничего особенного в ней нет. А вот оценить время до финального варианта действительно невозможно. Но тут тоже есть решение - если каждый прототип делать так, чтобы, в принципе, его можно было выкатить в прод, то бизнес имеет возможность просто в любой момент сказать, что текущий вариант good enough и он станет той самой финальной версией фичи.
2) Исследовательские задачи можно достаточно легко оценивать, просто это будет не одна оценка а последовательность из 2-3-4 оценок: первая на то, чтобы собрать общую инфу о проблеме и существующих подходах/решениях. И эта первая оценка обычно просто фиксированная, в зависимости от объёма и/или новизны данных, обычно день или два. И вот сколько данных успеешь собрать за это время - с теми и работаешь. Вторая оценка даётся по результатам инфы собранной на предыдущем этапе и она уже будет намного более точной. Обычно двух оценок хватает, но изредка сбор данных на первом этапе показывает только то, что нужно ещё неделю продолжать собирать данные (т.е. продлить первый этап), и без этого двигаться дальше нет смысла - тогда либо задачу отменяют вообще либо мы второй оценкой получаем эту самую неделю, а через неделю сможем уже оценить сколько времени нужно на решение задачи.
redfoxxy12
04.12.2024 12:30> Вот по этому и такая разница в зарплате
А курьер почему больше профессора получает? Потому что постоянно учит новые маршруты на райончике получается?
Бизнесу глубоко плевать учитесь вы или не учитесь если задача выполняется. Так получилось что сейчас цифровые сервисы приносят бизнесу огромные деньги, а для их создания нужны программисты. Вот и все. Которые еще и работать на зарубеж могут через Интернет, в отличие от скажем инженеров. И соответственно бустить тем самым планку зарплат.
Специальностей, в которых надо постоянно изучать что-то новое, достаточно. Та же медицина. И учить там надо намного больше информации, чем фронтэндеру.
kozel_rogatiy
04.12.2024 12:30Та же медицина. И учить там надо намного больше информации, чем фронтэндеру.
Всё это учится на этапе обучения. Далее если что-то новое и появляется/внедряется, то проходят годы исследований и согласований. Всё это давно изучено, давно описано и ничего кардинально нового там не появляется.
Хватит уже рассказывать байки про то, как много учатся в других областях. Я прихожу к взрослой-тетке терапевту в поликлинику с ярко выраженной болью в органах, в определенном месте, а она мне выписывает анальгин и не в состоянии даже предположить, что та может болеть. Учатся они, плять. Нихрена они там не учатся.
Атишка - самая мозговыносящая сфера, где среднечковый мидл по объему знаний и трудозатрат тянет на компетенцию профессора.
WindMill
04.12.2024 12:30Я делаю так: даю задание, спрашиваю про сроки. Начинают закатывать глаза, говорить что-то типа "нуууу, к лету в лучшем случае сделаем и то не факт". Беру аутсорс. 6 часов и готово. Урезаю премии. Опять даю задание. Глаза уже не закатывают, говорят "нууу, пару дней". Окей, работаем.
Quackerjack
04.12.2024 12:30Аутсорс - фигак-фигак и в прод заказчику. А дальше, случись чего мозговыносящие, две двери - костыли или "ящерицын хвост" + чернильное облако. Иногда, это поделие так и живет годами и все думаю. - "Почему так перестраховывалась?", но чаще, тем парням кто на галере с Вами, надо закладываться под масштабирование, поддержку и качественную конвертацию накопленных данных - им с этим жить, потому и перестраховываются. Истина - посередине +/- эпсилон умноженное на коэффициент выгорания мидлов.
Politura
04.12.2024 12:30Программисты хитрые, они не говорят "Мы не знаем, когда сделаем задачу", они говорят "AGILE". Существует два распространенных подхода к оценке задач в условиях неопределенности.
За 20+ лет в профессиональной разработке ни разу не слышал, чтоб кто-то на вопрос о сроках отвечал аджайл, всегда называли конкретные сроки и всегда задачам ставилась дата релиза. Разница лишь в том, что опытные в оценке команды и лиды чаще всего укладываются в назначенные сроки, неопытные в оценке очень часто не укладываются. Но если у неопытной команды опытный менеджер, он накинет время сверху и все будет нормально. :)
shushara4241
04.12.2024 12:30Неправильная оценка задач - это когнитивная ошибка (ошибка планирования) и к сожалению ей подвержены все, даже опытные специалисты. Единственный вариант - закладывать сроки, в которые с шансом 80-90% уложишься
pavelsha
04.12.2024 12:30Давайте будем честными... Содержание статьи вторично. Пока читал, начал жалеть, что кармы не хватит минусить её. Но имеет смысл простить за блок советов в конце.
Главные навыки - способность быстро учиться новому и эффективно взаимодействовать с командой.
Если чего-то не знаешь - это нормально, спроси.
Если не успеваешь к срокам, о которых договорились, это нормально, главное скажи об этом как можно раньше, и подсвети что не учли при оценке.
А если ты только в поисках первой работы, не пробуй выучить все, иди на собеседование, возможно ты уже знаешь достаточно.
monpa
Кошмар... Одни Пятнадцатерублевые боты в комментариях.... Куда катится Хабр...