Привет! Если ты сейчас учишься программировать, и думаешь что‑то вроде «Вот выучу все, и тогда пойду на собесы», то у меня для тебя плохая новость — выучить все невозможно. Это осознание пришло ко мне только спустя несколько лет работы 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 стори-поинтов. Оценивать кстати - тоже непросто, для этого есь отдельный ритуал - planning 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 скилам, и поэтому тебе не нужно знать все.
Главные навыки - способность быстро учиться новому и эффективно взаимодействовать с командой.
Если чего-то не знаешь - это нормально, спроси.
Если не успеваешь к срокам, о которых договорились, это нормально, главное скажи об этом как можно раньше, и подсвети что не учли при оценке.
А если ты только в поисках первой работы, не пробуй выучить все, иди на собеседование, возможно ты уже знаешь достаточно.
Комментарии (211)
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 закопается на целый день, но ему делать нечего, поэтому ему поручим, и срок будет два дня"
piton_nsk
04.12.2024 12:30Скорость выполнения в часах зависит от человека/команды
когда до каждой дело доходит, уже идет "ну A такое сделает за два часа, но у него завал, а B закопается на целый день
И в чем разница? Правильно, ни в чем.
зная среднюю скорость в сторипоинтах в месяц, абстрактно задач напихать в бэклог "типа чтобы до конца года хватило плюс-минус"
Перефразирую - зная среднюю скорость в часах в месяц, абстрактно задач напихать в бэклог "типа чтобы до конца года хватило плюс-минус".
В реальности тут есть нюанс, чтобы напихать задач в бэклог до конца года надо их все оценить (неважно в чем), лучше спринтами, но это тонкости.
vvbob
04.12.2024 12:30насколько задача простая для всей фирмы
Тоже какая-то средняя температура по больнице. Для одного человека, который допустим эксперт по какому-то фреймворку, задача вообще ерунда на полчаса неспешной работы, для другого эта же задача на день - пока разберешься, пока поймешь что делать, пока ошибки отладишь..
А одного эксперта на все задачи может и не хватить, он не резиновый, вот и получится что один черт измеряется этими сторипоинтами что-то непонятное и с потолка.
Nalivai
04.12.2024 12:30Они и есть средняя средняя температура, в этом и прелесть, для этого они и нужны. Размазано по долгому сроку, они дают достаточную плюс-минус оценку, без того чтобы на этапе предварительного планирования вдаваться в мелочи типа кто что за сколько времени делает. При достаточно грамотном использовании, они дают достаточно достоверный метод быстро прикинуть сколько всего можно сделать за сколько времени, в среднем, абстрактно, без подробностей. Вместо того чтобы закапываться сразу в гранулярное планирование, которое все равно в итоге покажет погоду на марсе.
Kanut
04.12.2024 12:30Например чтобы потом не было претензий а ля "Тебе дали на день задач на восемь часов, а ты сделал только на 6. Чем ты занимался два часа?".
piton_nsk
04.12.2024 12:30Разве оценка в сторипойнтах уберет такие мудацкие претензии? Просто станет вот так "Тебе дали на день задач на
восемь часовна два сторипойнта, а ты сделал толькона 6на один сторипойнт. Чем ты занималсядва часаоставшееся время?"Мудацкие претензии и способ оценки задачи вещи несвязанные. Можно и до сторипойнтов докапаться, можно и по часам оценку нормально использовать.
Kanut
04.12.2024 12:30Но при этом я могу задать один простой вопрос: А где написано что за день надо делать ровно два сторипоинта?
Newbilius
04.12.2024 12:30"Все остальные делают в среднем 2 сторипоинта, значит и ты должен"
Напомним, что вводная - "у менеджера есть цель докопаться", от неё замена часов сторипоинтами не спасает.
Kanut
04.12.2024 12:30Ещё как поможет. Потому что разработчику тоже никто не мешает "включить дурака" и начать докапываться уже до менеджмента на каком основании ему выдвигают претензии.
И если задача оценена в часах, то отбиться будет гораздо сложнее.
piton_nsk
04.12.2024 12:30на каком основании ему выдвигают претензии
Докопаться можно и до столба, почему он стоит. А тут докопаться проще простого - все перформят 2 СП в день, ты раньше перформил 2 СП в день, а теперь один, халявишь поди.
На всякий случай уточню свою позицию - я не говорю что это хорошо, что это правильно, что это повсеместно. От мудаков замена часов на сторипойнты не спасет, найдут к чему прицепиться.
Kanut
04.12.2024 12:30все перформят 2 СП в день
Их проблемы. Где у меня в трудовом договоре написано сколько СП в день я должен перформить?
От мудаков замена часов на сторипойнты не спасет, найдут к чему прицепиться.
Это может быть не спасает в любой ситуации. Но это увеличивает шансы.
П.С. А вообще если такое начнётся, то мне с фирмой не по пути. И вопрос скорее идёт о том с какой компенсацией меня уволят.
piton_nsk
04.12.2024 12:30Ответ зависит от степени мудаковатости.
Легкая степень - ну как откуда, по результатам последних десяти спринтов средняя производительность в день 2,17 СП. При планировании спринта на тебе 20 СП. Не, если оценка неверная, ты скажи, мы на ретро все подробно обговорим. А пока завтра на дейлике подробно расскажи какие у тебя были проблемы, обсудим.
Тяжелая степень - а сколько тебе надо, неделю что ли? Скоуп работ на тебе есть, там два СП в день. Или может хочешь вообще без сроков и планирования работать, типа когда сделаю, тогда сделаю? Так не пойдет. Если задача большая, разбивай на подзадачи не больше одного дня. В общем, когда будет готово? Назови точный срок.
Kanut
04.12.2024 12:30Отвечать они могут что угодно. При этом если уж такое начнётся, то только письменно.
А потом уже в зависимости от "степени мудаковатости" будет привлечён мой начальник или начальник моего начальника или даже адвокат.
Но в любом случае сторипоинты дают разработчику больше "амуниции" для таких разборок. Потому что получается что лично он под конкретным сроком нигде не расписывался.
piton_nsk
04.12.2024 12:30Потому что получается что лично он под конкретным сроком нигде не расписывался.
Ну будут всей команде мозги сношать) От неадекватов сторипойнты не помогут.
R3B3LL10N
04.12.2024 12:30Был у нас разговор с аналитиками буквально на той неделе... я им про часы, а они мне - один про футболки, второй про сторипоинты. Мол, в часах оценить невозможно. Зато вот футболка XXL и 10 поинтов - это большааая задача. И можно прикинуть что она стоит примерно... 40 часов.
Я им - так получается всё равно к часам возвращаемся? Ну да... но нет... но да...
Короче, это всё равно что спорить в чём мерить длинну - в футах или в метрах. Где как принято, там так и мерят. Хуже всего получается когда у одних фут британский (~0.3м), у других бразильский (~0.33м), а у последних римский (0.25м). Потому-что ноги у всех разные, как и размеры футболок или, прости господи, стори поинтов.
К чему я? Да к тому что есть универсальная, а главное, точная единица - часы. Точнее неё вам ни поинты, ни футы, ни футболки, ни любая другая абстрактная единица не оценит задачу.
powerman
04.12.2024 12:30Да, всё-равно возвращаемся к часам. Но, нет, это другое. :-)
Фишка в том, что оценка в сторипоинтах универсальна для всех разработчиков, потому что описывает относительную сложность задачи - относительно другой, минимальной, задачи. А вот оценка в часах для разных разработчиков для одной и той же задачи может очень сильно отличаться - в зависимости от кучи факторов, начиная от джун/сениор и заканчивая тем знаком ли конкретный разработчик с данным типом задач и насколько конкретно этот разработчик любит затягивать задачи делая разные посторонние штуки (напр. пытаясь сделать более гибкое/универсальное/красивое решение чем реально необходимо).
Поэтому переводить в часы имеет смысл когда уже понятно кто именно из команды будет делать эту конкретную задачу. И если задача передаётся от одного разработчика другому то оценку в часах нужно корректировать. И это ещё простой случай, потому что если обсуждаемая задача не является низкоуровневой микротаской для разработчиков а является более высокоуровневой бизнес-задачей, над которой по определению должны работать несколько разных людей (дизайнер, разработчик, тестировщик), то такую в часы конкретного разработчика в принципе переводить бессмысленно, и можно только статистически через какое-то время выяснить среднее отношение между сторипоинтами и человеко-часами (а, скорее, человеко-неделями).
Поэтому и получается так, что "перевести в часы" - можно, а сразу назвать "в часах" - нет.
WebPeople
04.12.2024 12:30В вашей логике есть изъян, вот в этом месте:
Фишка в том, что оценка в сторипоинтах универсальна для всех разработчиков, потому что описывает относительную сложность задачи - относительно другой, минимальной, задачи
Сторипойнты тоже не универсальны. Все что вы описываете про часы - уместно и для сторипоинтов. Или все разработчики способны оценивать сложность задач одинаково? Пусть даже относительно простой задачи?
Для выравнивания оценок в сторипойнтах придумали целый ритуал с покер планированием.
Вот и возникает вопрос, а нафига они нужны? Почему сразу не использовать часы, если нет разницы? Звучит более модно? Цифры Фибоначчи проще воспринимать чем реальные часы? Или это такой способ сбросить ответственность?
Иногда доходит до абсурда, когда и часы и сторипойнты используют. И потом переводят сторипойнты в часы, чтобы дать стецкхолдерам прогноз по срокам. Или чтобы по методу освоенного объема контролить показатели проекта.
Кстати, большие куски работы даже проще оценивать. Особенно если есть похожий опыт. Например, интеграция платежной системы, ага, 3 недели, 120часов. И выставляешь по перту 100ч в идеале, 160ч пессимистично, и считаешь по формуле смещенное среднее.
powerman
04.12.2024 12:30Или все разработчики способны оценивать сложность задач одинаково?
А вот тут и появляется польза от Фибоначчи. Да, мнения разных разработчиков про задачу "раза в 2 сложнее самой простой" скорее всего совпадут, а вот в отношении задачи "раз в 5 сложнее самой простой" скорее всего разойдутся: кто-то скажет в 4 раза, кто-то в 5, кто-то в 6 - и тут очень удобно, что среди возможных ответов есть только 5. Между вариантами "в 2 раза" и "в 8 раз" мнения обычно не расходятся, а если такое и происходит, то это повод подробнее обсудить в чём причина расхождения, после чего обычно мнения синхронизируются на одной из оценок.
piton_nsk
04.12.2024 12:30Фишка в том, что оценка в сторипоинтах универсальна для всех разработчиков, потому что описывает относительную сложность задачи - относительно другой, минимальной, задачи. А вот оценка в часах для разных разработчиков для одной и той же задачи может очень сильно отличаться
Не будет она универсальная, что для одного сложно, для другого просто, кто-то опытный, кто-то нет. Кто-то похожую задачу делает уже в нный раз и все знает, а кто-то в первый и ему разбираться там что да как.
Поэтому переводить в часы имеет смысл когда уже понятно кто именно из команды будет делать эту конкретную задачу.
А зачем вообще это делать? Контролировать время по каждой конкретной задаче это хрень. Есть производительность в сторипойнтах у команды в целом, кто-то больше выдает, кто-то меньше. Если мерить в сторипойнтах, конечно.
такую в часы конкретного разработчика в принципе переводить бессмысленно
Оценка имеет смысл для команды в целом и в среднем за спринт. Так все усредняется и можно дать более-менее реалистичный прогноз. А в одной конкретной задаче неопределенность слишком большая. Неважно как оценивать.
можно только статистически через какое-то время выяснить среднее отношение между сторипоинтами и человеко-часами
Как ни крути все в конечном итоге превращается в часы.
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, и заканчивая тем, что в этих мелких задачах редко закладывают риски связанные с интеграцией/прохождением ревью безопасников/ожиданием дизайнера или тестировщика и т.п. Тем не менее, это всё решаемые проблемы - как отдельной оценкой крупной бизнес-таски традиционными способами так и налаживанием процессов которые будут минимизировать упомянутые риски.
Kergan88
04.12.2024 12:30Оценка такой мелкой таски будет тем точнее, чем меньше таска.
Я и говорю - это просто глупость, которую один дурак когда-то сказал, а остальные дураки - повторяют.
но и сами риски по мелким таскам тоже мелкие
На самом деле риски по мелким задачам существенно крупнее, чем по большим. Это достаточно очевидно. Но даже если их не считать больше, а считать такими же - то в итоге для большой задачи оценка будет точнее все равно.
Если у вас есть несколько одинаковых независимых случайных величин с положительным матожиданием, и вы их будете суммировать - то матожидание растет линейно от n (количества задач), а стандартное отклонение - пропорционально корню, с-но точность оценки растет пропорционально корню от размера задачи (на самом деле даже не самой оценки - а в принципе неопределенность в сроках уменьшается, с-но уменьшается и неопределенность в оценке).
Это как бы очевидно и на конкретных примерах - допустим, у вас есть задача на два часа. Если вдруг случится какой-то несущественный риск - то вместо 2 часов будет 4 часа, это 100% отклонения. И такие отклонения для задач подобного размера - обычное дело, они постоянно происходят и на них особ внимания ни кто не обращает. С другой стороны, если у вас задача на год, то 100% отклонение крайне маловероятно (и считается уже не нормой, фактически это проваленный проект в 9 случаях из 10).
Точность оценки в случае маленьких задач возникает просто из-за того, что они лучше и подробнее поставлены - любая неопределенность в постановке всегда закладывается в риски, т.е. в + к оценке, что снижает точность. Маленькие задачи же ставятся конкретно, что снижает неопределенность. Если же большая задача и маленькая поставлены одинаково - то для большой задачи ниже риски, с-но точнее оценка.
powerman
04.12.2024 12:30Судя по всему, Вы - математик: даёте точный, но совершенно бесполезный ответ.
На практике у нас и величины не случайные, и точность оценки маленьких задач возникает не только потому что они лучше и подробнее поставлены (нередко всё совсем наоборот, из-за того что задача маленькая она вообще детально не описывается помимо того что в названии задачи), и в случае "задачи на год" типичное отклонение будет не 100% (которое Вам кажется маловероятным) а все 200% (потому что сроки в среднем срываются в 3 раза), и нет, срыв сроков по маленьким задачам - это исключение, а не "обычное дело".
То, что Вы описали - это теория. Причём базирующаяся на неверных входных данных, что ещё больше всё портит. А я описываю как оно работает на практике. И на практике единственный работающий способ получить достаточно точную оценку сколько времени займёт реализация функционала размером примерно на 3-4 человеко-месяца - это декомпозировать его на задачи размером от 1 часа до 3 дней, сложить сроки задач и умножить на корректирующий коэффициент для конкретной команды, причём чем меньше будут задачи тем точнее получится финальная оценка.
Я даже допускаю, что если понять фразу "чем меньше таска" буквально (как математик) и попытаться дробить на задачи не в интервале 1 час - 3 дня (со средним размером задачи примерно 0.5-1 дня) а на задачи в интервале 1-60 минут (со средним размером задачи в 23 минуты), то мы действительно получим описанный Вами результат в виде сильного уменьшения точности оценок. Но на практике так всё-равно никто не делает, потому что глупость такого подхода очевидна всем.
Wesha
04.12.2024 12:30оценка маленьких задач всегда будет точнее
...вот только непонятно будет — придётся ли эту маленькую задачу делать, или мы решили пойти другим путём.
vvbob
04.12.2024 12:30Да и то не особо оно работает. Точнее работает, но на очень ограниченном подмножестве задач. Всякие простые доработки в простом и вдоль и поперек изученном фреймворке - да, тут более-менее. А уже исправление багов - нифига не работает. Вот поступил баг - какие-то данные обсчитываются не так как должны (не все подряд и не всегда, только в некоторых случаях). У разраба спрашивают - сколько времени надо на исправление? В подавляющем большинстве случаев он просто не знает этого. Не знает потому что само исправление обычно занимает считанные минуты, а вот поиск места, куда это исправление надо внести, может потребовать часы, а то и дни или недели. Бывают такие гадкие баги, что исправляются они чуть ли не месяцами и разными разрабами.
Та-же ерунда и с новым функционалом, который делается не по старой, накатанной схеме. В процессе могут всплыть столько неучтенных нюансов, что ни о какой определенности и говорить нечего.
gun_dose
04.12.2024 12:30Это тоже решается. Просишь N часов на инвестигейт. Далее ПМ объясняет клиенту, что вот у нас тут неведомая фигня, надо столько-то часов только чтобы понять, что это.
vvbob
04.12.2024 12:30И как понять - сколько просить? Вот я уже очень много лет работаю и до сих пор не знаю "сколько в часах". Ну да, я на практике прошу обычно какое-то время, но это всегда оценка по большему счету с потолка взятая. Бывает что очень быстро разберешься, а бывает что днями логи и код изучаешь, и ходишь кругами около какой-то особо заковыристой проблемы, а потом оказывается что там какая-либо ерунда была, исправляемая парой строчек кода..
powerman
04.12.2024 12:30Сначала просить немного, чтобы хватило просто вникнуть в контекст и оценить насколько данный баг простой/сложный/неведомая хрень. Если баг окажется простым, то он за это время будет заодно и исправлен. Если сложным, то за это время получится выработать вторую, более точную оценку сколько времени потребуется на его выявление и обнаружение. Если за это время даже идей никаких не появилось т.е. понимания больше не стало, то это значит что в этот баг можно закопаться на неопределённое время, и тогда нужно просто двигаться "интервалами" - выделять фиксированное время (день/два) после которого принимать решение стоит ли вообще продолжать исследовать этот баг данному разработчику (выделяя следующий день/два), или лучше передать его более квалифицированному разработчику либо вообще забить и не исправлять его (ну или заткнуть каким-то хаком).
vvbob
04.12.2024 12:30Ну, в сущности я о том и говорил изначально, есть довольно большое подмножество задач, по которым точные сроки выдать либо просто невозможно, либо очень сложно и на это не все способны (дело даже не в профессионализме, может сыграть просто больший опыт с конкретной системой)
Kwisatz
04.12.2024 12:30Спрашивает разработчика?))
1. Если пм спрашивает разработчика это не пм вовсе а передаст и ставку его лучше отдать разрабам или понизить до секретаря и все равно отдать разрабам
2. а разработчик откуда знает? Я понимаю что вы привыкли выжимать из разрабов эти оценки но они абсолютно с неба взяты. Я вот +- могу на длинной дистанции как то оценивать и для этого мне всего то потребовалось 20 лет опыта, фигня какая...
3. потрекать время? самое беспощадное и бесполезное занятие которое вообще бывает. По целому ряду причин, начиная с мнения что якобы платят за время а не за 20 лет опыта, и заканчивая тем что в таком случае можно вносить 24 часа в табели, поскольку некоторые разработчики думают над задачами на прогулках и перекурах.gun_dose
04.12.2024 12:30якобы платят за время а не за 20 лет опыта
Хотите сказать, что вы можете себе позволить вообще не работать ни одного часа (ой, простите, сторипоинта) в месяц и вам заплатят полную зарплату? Так вы же можете тогда устроиться одновременно во все компании в мире и получать зарплаты в них всех!
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 часов, что тоже не сильно информативно.
gun_dose
04.12.2024 12:30вы
ваше
Мне не очень нравится то, как вы ведёте дискуссию. Я рассуждаю о проджект-менеджменте, а вы рассуждаете обо мне лично и моём лично опыте работы. В который раз делаете обо мне какие-то предположения и ставите эти умозаключения мне в упрёк. Я бы советовал вам ещё раз перечитать нашу дискуссию и сделать какие-то выводы о своём стиле общения.
вы, вероятно, работаете на износ
И вновь мимо. Я не работаю на износ по двум причинам. Во-первых, я умею корректно оценивать время выполнения задач. Во-вторых, я умею выполнять эти задачи достаточно качественно и быстро. И моё высокое самомнение (чего уж скрывать, оно действительно такое) основано исключительно на результатах моей работы и на отзывах о ней моих коллег и клиентов.
в детсаду я выполняю гораздо более интересные и масштабные задачи
Вы не открыли Америку. Я думаю, если вы опросите тысячу человек, где им было интереснее - в детсаду или на работе, то все дружно ответят, что в детсаду было интереснее.
Drucocu
04.12.2024 12:30А мне нравится, когда человек первым комментом к статье пишет
Чушь полная.
Сверху поливает это фразами, типа
происходит инфантилизация IT-сообщества и придумываются всякие детсадовские понятия
А потом удивляется, почему ему напихали полную панамку и предъявляет всем за стиль общения. На себя посмотрите.
Drucocu
04.12.2024 12:30И моё высокое самомнение (чего уж скрывать, оно действительно такое) основано исключительно на результатах моей работы и на отзывах о ней моих коллег и клиентов.
Господа Джастин Крюгер и Дэвид Даннинг понимающие вам улыбаются.
gun_dose
04.12.2024 12:30С Даннингом-Крюгером у вас та же история, что с веб-студией, лучше перечитайте определение, прежде чем сыпать терминами. Эффект Даннинга-Крюгера не может быть применим там, где самомнение строится на основе оценок окружающих.
Drucocu
04.12.2024 12:30Да ну? И где такое сказано в определении? Вижу указание на компетенцию. Увы, если ваши коллеги обладают сходным с вами уровнем компетенции, эффект применим к вам в совокупности - вы просто не знаете, что может быть как-то по-другому. Ну либо вы подвержены другому искажению и не замечаете критики в свой адрес.
В целом, если вам кажется, что обладая вашим опытом, вы досконально разобрались в профессии и можете так категорично раздавать советы - это звоночек.
gun_dose
04.12.2024 12:30Давайте попробую подвести небольшой итог дискуссии. Значит я назвал фразу "Оценивать в часах бессмысленно" чушью, аргументировав своё решение рядом примеров из личного опыта. В ответ от вас я лишь услышал, что у меня голова засунута в песок, у меня мало опыта, я работаю в плохой компании, где плохо относятся к сотрудникам. А также что в целом моя квалификация оставляет желать лучшего, равно как и квалификация моих коллег. При этом я на 200% уверен, что вы не знаете лично ни меня, ни моих коллег, не знаете, где я работаю, а если бы и знали, всё равно ничего бы не знали об этой компании.
В общем, не вижу ни малейшего смысла продолжать разговор с вами.
Drucocu
04.12.2024 12:30аргументировав своё решение рядом примеров из личного опыта
А я в ответ пытаюсь вам донести, что ваш личный опыт не распространяется на всю индустрию. Мысль, от обсуждения которой вы уходите всеми возможными способами, попутно обижаясь, что с вами грубо общаются. При этом не стесняетесь всем остальным рассказывать, как неправильно они работают и вообще "устраивают детский сад".
Да, на этом и закончим.
Wesha
04.12.2024 12:30самомнение строится на основе оценок окружающих.
Помнится, я что-то такое читал, там было что-то про короля и патье...
piton_nsk
04.12.2024 12:30но для меня любое место, где надо логировать время - это галера.
тот факт, что вам ближе к 40, также объясняет вашу категоричность
И у кого тут категоричность)
Nalivai
04.12.2024 12:30в любой галере проджект-менеджмент априори должен работать лучше, чем в продуктовой компании
You would think, но на самом деле нет. Галеры закладывают столько оверхеда в цену для клиента, что плюс-минус год разработки вообще ни на что не влияет. Особенно в тру галерах, где кучи людей на бенче, которых во-первых надо кормить, а во-вторых всегда можно призвать в усиление если команда не осиливает, и где куча продажников у которых единственная цель это сделать так чтобы клиент с ними остался на подольше, и она в том числе включает в себя оправдание долгих сроков.
А вот точная оценка сроков выполнения в этом мире дело вторичное уже.
gun_dose
04.12.2024 12:30Галеры закладывают столько оверхеда в цену для клиента, что плюс-минус год разработки вообще ни на что не влияет.
Так это и есть показатель хорошего менеджмента - взять с клиента максимально возможную сумму за то, чтобы сделать минимум работы. Другое дело, сколько из этого оверхэда дойдёт до карманов разработчиков, но для этого и придумали отзывы работников о компаниях
Drucocu
04.12.2024 12:30Вот поэтому лично я и не хочу больше связываться с галерами. С одной стороны, с клиента дерут максимум денег, с другой, с разработчика требуют уложиться в минимальные сроки, заставляя логировать каждый час времени. Это какое-то круговое очковтирательство, где никто из участников не может адекватно ответить, что происходит.
Nalivai
04.12.2024 12:30Вот у вас здорово, что не поверни все хороший менеджмент. Знают сколько займет разработка - очень хорошо, понятия не имеют - так еще лучше.
gun_dose
04.12.2024 12:30Плохой менеджмент - это когда есть недооценка стоимости и/или недооценка сроков, а клиент при этом не хочет платить и/или ждать, потому что это приводит к овертаймам у сотрудников и/или финансовым потерям компании.
Если же менеджмент называет завышенную оценку, но в рамках того, что клиент готов заплатить, то это хорошая сделка. Вопрос в том, что бесконечно завышать нельзя, потому что "рыночек порешает" рано или поздно.
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 часа, так как может быть простая задача, в которой надо кучу файлов править руками или тестов, т.е. ничего сложно, но занимает много времени, причем одинаково, что у синьора, что у джуна.
gun_dose
04.12.2024 12:30Сторипоинты - это все таки оценка сложности задачи, а не времени затраченной.
Пример сложной задачи - постоянно отваливается база с таймаутом. Надо посмотреть логи и подправить запрос. Джун не справится, поэтому напишем 100 сторипоинтов.
Пример простой задачи - ввести данные миллиона человек из церковных книг в базу. Тут всё проще некуда, поставим один сторипоинт.
Или всё-таки время выполнения как-то связано со сторипоинтами?
rpc1
04.12.2024 12:30Зачем 100? по моему вы слишком утрируете. Сторипоинты сложно конвертировать в часы если вы об этом, но как правило, чем выше сложность задачи тем дольше она будет делаться. Чем выше сторипоинт, тем сложнее определить время, которое на нее будет затрачено, так как в это закладывается помимо объема работы, еще неопределенность, сложность и другие факторы.
Нужно учесть, что сторипоинты - это абстракции, которая может зависеть от компании (я никогда не видел задачу на 100 поинтов), не существует какого ГОСТ сторипоинт = 8 часо.
P.S. Если кто-то хочет измерять задачу в часах, то пожалуйста, команды должны работать как им удобно.
R3B3LL10N
04.12.2024 12:30Тогда я вообще ничего не понимаю. Допустим у меня посчитано что ресурс разраба - 10 сторипоинтов в спринт. Закинут на Васю 10 поинтов. На Олега тоже. Только у Васи - 10 рефакторингов которые он когда-то оценил по поинту, но занимают они дофига времени. А у Олега очень сложная интеграция и надо перелопатить 5 страниц доки из которой станет понятно что надо вставить один скрипт на страницу и прокидывать его ответ на бэк, с чем Олег управился всего за день.
Получилось Олег всё сделал и сидит довольный, а Вася даже половины не успел. Как мне с точки зрения менеджмента планировать спринт тогда? Сложность далеко не всегда коррелирует со временем.
Получается нужно совмещать подход. Оценить и сложность, и трудоёмкость (времязатраты) задачи. И мы опять уйдём в часы. Потому-что люди работают не сторипоинтами, а часами. И заказчик ждёт не сторипоинты, а время, которое уйдёт на его заказ.
Kanut
04.12.2024 12:30Получается нужно совмещать подход
Нет. Вам(ну или Васе) просто нужно после этого понять что рефакторинг занимает больше времени и оценивать его по другому.
То есть после каждой итерации смотреть что оценили неправильно и почему. И корригировать то, как вы оцениваете.
И мы опять уйдём в часы. Потому-что люди работают не сторипоинтами, а часами. И заказчик ждёт не сторипоинты, а время, которое уйдёт на его заказ.
Никто не работает с часами.
Разработчикам вообще ничего из этого не нужно. Они делают задачу пока она не готова.
Заказчика часы под каждую задачу тоже по хорошему не интересуют. Ему интересно сколько это будет стоить и просто чтобы было готово в срок.
R3B3LL10N
04.12.2024 12:30Так откуда с вашими поинтами сроки то берутся??? 10 поинтов - это что? Когда будет готова задача? Если она в срок не сделана, то это чья проблема - разраб некорректно оценил и не уложился в оценку или оценку неверно конвертировали в срок?
Kanut
04.12.2024 12:3010 поинтов - это что?
Это сложность задачи. При этом вы точно так же знаете что скажем команда в среднем делает 50 сторипоинтов в неделю.
R3B3LL10N
04.12.2024 12:30Абстракция на абстракции. Как и в статье сказано - это измерение в попугаях. Сложность задачи и в часах можно оценить. Мне кажется суть тут просто в том чтобы оценки звучали не так страшно. 30 человекочасов - звучит дорого. А 10 поинтов - ну нормально, наверно. Всё равно эти поинты могут сконвертироваться хоть в 5, хоть в 25 часов.
Kanut
04.12.2024 12:30Сложность задачи и в часах можно оценить
Можно. Но эти часы из оценки всё равно в большинстве случаев не будут совпадать с тем сколько времени реально будет потрачено на реализацию. То есть это точно такая же абстракция.
Всё равно эти поинты могут сконвертироваться хоть в 5, хоть в 25 часов.
Так и ваши часы из оценки точно так же могут сконвертироваться в какое-то другое количество часов в реальности.
R3B3LL10N
04.12.2024 12:30Всё так. Потому-что риски и форс-мажоры никто не отменял. Мне было интересно чем поинты лучше часов раз их так защищают и продвигают.
Как и подозревал - ничем. Те же яйца, только в профиль. Хоть длинной члена мерить, а всё разные названия для одного и того же.
И опять возвращаемся к началу - нахрена выдумывать абстрактные единицы непонятно чего, если люди давно придумали единицы измерения? Получается незачем. В часы можно точно так же заложить и риски, и сложность, и примерные времязатраты среднего разработчика. Эта единица будет понятна даже ребёнку. А вес и понимание что такое поинт у всех своё.
Kanut
04.12.2024 12:30Мне было интересно чем поинты лучше часов раз их так защищают и продвигают
Например потому что они не создают иллюзию того, что оцениваются действительно реальные часы.
И опять возвращаемся к началу - нахрена выдумывать абстрактные единицы непонятно чего, если люди давно придумали единицы измерения?
Потому что это примерно как мерить расстояние в миллиметрах ртутного столба.
Сложность задач не измеряется в часах или там днях. По хорошему для неё нужны собственные единицы измерения.
R3B3LL10N
04.12.2024 12:30Не согласен. Ставлю 12 часов - значит задача сложная или рутинная и займёт много времени.
Ставлю 10 поинтов - будет означать ровно то же самое.
И манагер в обоих случаях видит, что минимум полтора-два дня по ресурсу уже занято.
Kanut
04.12.2024 12:30Ставлю 12 часов - значит задача сложная или рутинная и займёт много времени.
Почему бы тогда и расстояние не измерять временем?
Ну то есть если ставлю 10 часов, то значит дорога длинная и займёт много времени. О каком расстоянии я говорю?
И манагер в обоих случаях видит, что минимум полтора-два дня по ресурсу уже занято
Минимум два дня? Максимум два дня? Ровно двадцать часов?
Если вы поставите сорок часов, то будет менеджер ожидать что работа будет сделана за неделю? Готовы вы ему это гарантировать?
R3B3LL10N
04.12.2024 12:30О каком расстоянии я говорю?
Вспомните школьную программу и посчитайте, если скорость известна. Навигаторы, к слову, вам время дороги в часах и озвучивают. Пример совершенно невалидный.
Минимум два дня? Максимум два дня? Ровно двадцать часов?
Договоритесь заранее по оценкам и всё. Мы на груминге даём максимальную со всеми неизвестными. И она, естественно, может поменяться в обе стороны, если появятся новые вводные. Это проблема аналитиков или заказчика, если он меняет что-то на ходу, а не разработки.
Если вы поставите сорок часов, то будет менеджер ожидать что работа будет сделана за неделю
А Если 10 поинтов, то что? Вот вы и вскрылись - просто пытаетесь снять с себя ответственность за оценку и запутать сроки.
Но только это так не работает. Менеджер в любом случае будет ждать задачу в какой-то срок. Он сконвертирует поинты в примерные часы, как ему это видится. Иначе определить срок сдачи задачи НЕВОЗМОЖНО. Время идёт в часах. Всё. Это аксиома.
Что в это время войдёт - сложность, риски, объём и прочее уже лирика. В ваш поинт точно так же это всё будет закладываться. А если нет - я вас расстрою. У вас в целом хреновое планирование. И то в каких единицах его размечать не является проблемой.
Kanut
04.12.2024 12:30Вспомните школьную программу и посчитайте, если скорость известна.
Так в том то и дело что скорость неизвестна. Об этом и речь.
Поэтому глупо измерять расстояние в часах. И сложность тоже.
А Если 10 поинтов, то что?
То менеджер знает оцененную сложность задачи. И ему даже в голову не придёт что эта сложность говорит о том, сколько конкретно времени займёт реализация.
А дальше он может сам думать и сколько каких задач он хочет запланировать на какое отрезок времени. Под свою ответственность.
Разработчики оценивают сложность. Менеджер планирует сроки. Это разные вещи. Зачем использовать для разных вещей одни и те же единицы измерения? Тем более если и то и другое используют в одном контексте?
R3B3LL10N
04.12.2024 12:30Смысл понял, но мне кажется вы идеальный мир описываете, где все понимают что поинт - не точная оценка. На практике пуши "а где задача? Ты всего в один поинт оценил, чё так долго?" никуда не денутся, если менеджмент хреновый.
И то чем задача мерится не решит эту проблему.
Kanut
04.12.2024 12:30Я как раз таки пишу о реальном мире. Где некоторые менеджеры, или тем более клиенты, если видят что задача оценена в 10 часов, считают что это срок, который уйдёт на разработку.
Поэтому практически во всех фирмах, где я работал, рано или поздно уходили от оценки в часах к другим вариантам.
rpc1
04.12.2024 12:30Сложность далеко не всегда коррелирует со временем.
Вот именно, стоирпоинт включает ни только объем работы, но и сложность этой работы и неопределенность. Поэтому чем выше сторипоинт, тем тяжелее переводить в часы. Вы как менеджер уже можете оценивать время при распределении задач в спринте, в зависимости от того кому она назначается.
Вася получил задачу со сторипоинт 5 - с высокой степенью неопределенности (в новом для него домене), ему нужен спринт или 2 ее сделать.
Олег получил 10 задач по одному сторипоинту, где нужно сделать мелкие изменения, ему можно еще накинуть.Я не уверен, что линейный подход здесь будет работать - например 10 сторипоинтов на спринт для разработчика, по описанным выше причинам.
ris58h
04.12.2024 12:30Да при чем здесь это?
Конкретно про последний параграф речь:
В часах оценка плоха тем, что всегда есть куча активности, которая двигает процесс в целом - например - ответить на вопрос коллеги, но к конкретной задаче не относится. Короче я не видел чтобы хоть раз оценка в часах нормально работала и не приводила к бесплатным овертаймам или вопросам - а почему на это ушло столько часов
Отвлёкся на сторонний вопрос и задачу в спринт выполнить не успел. Как СП здесь поможет?
MagisterAlexandr
04.12.2024 12:30Короче я не видел чтобы хоть раз оценка в часах нормально работала и не приводила к бесплатным овертаймам
В том и смысл.
Drucocu
04.12.2024 12:30А теперь вынимаем голову из песка и вспоминаем, что далеко не все IT-компании организованы по принципу галер (к нашему общему счастью).
Поэтому рассуждения на тему, как заставить разработчика постоянно испытывать стресс за "неверно выставленные сроки" и выжимать из него все соки, пока не сдохнет, оставляем себе и в приличном обществе не показываем.
Kanut
04.12.2024 12:30Все ваши сторипоинты потом всё равно сконвертируются в часы, потому что каждый сотрудник работает 40 часов в неделю, и никак иначе.
Ну неправда же. Никто в реальности не работает 40 часов в неделю. И уж тем более не работает конкретно над задачами всё это время.
И если мерить так, то и начинаются вещи вроде "Тебе дали задач ровно на 40 часов, а сделал ты на 30! Причём здесь какие-то совещания?!"
Игнорировать тот факт, что бухгалтерия в расчётах оперирует часами, это то же самое, что заметание мусора под ковёр
Вы тут пытаетесь сравнивать тёплое с мягким.
Это же получится средняя температура по больнице
И это лучше чем никакая.
При этом вы сами написали "понятно, что каждый сотрудник может выполнить разный объём работы за эти 40 часов", но почему-то не считаете это проблемой при вашем способе учёта.
По какому сотруднику вы собираетесь измерять сколько времени нужно на задачу? По самому быстрому? По самому медленному? По среднему?
gun_dose
04.12.2024 12:30Причём здесь какие-то совещания?!
Как причём? Совещание - это такой же рабочий процесс, как и написание кода, поэтому оплачивается по той же ставке. Если я совещаюсь полдня, это значит, что на другие задачи мне сегодня надо потратить только 4 часа, а не 8. Время, затраченное на совещания, как правило, логируется в специальную задачу. И в любом спринте всегда должно быть запланировано определённое количество времени на совещания.
По какому сотруднику вы собираетесь измерять сколько времени нужно на задачу?
По тому, который будет выполнять эту задачу. А по какому ещё? Любой адекватный проджект понимает, что если задача была оценена в 1 час и планировалось, что её сделает сеньор, то если задачу планируют передать джуну, то эстимэйт нужно пересмотреть.
По среднему?
Вот тут и зарыта собака. Сторипоинт - это производительность среднего работника, умноженная на определённый коэффициент. А каждый участник команды должен иметь свой собственный коэффициент перевода сторипоинтов в часы. Условно джун сделает задачу в 10 сторипоинтов за 5 часов, а сеньор за 1. Поэтому у джуна коэффициент 2, а у сеньора 10. Но это тоже никакая не серебряная пуля, потому что 5 джунов не заменят ни одного сеньора. И начиная с определённого уровня сложности джун со сложной задачей может вообще не справиться.
Kanut
04.12.2024 12:30Совещание - это такой же рабочий процесс, как и написание кода, поэтому оплачивается по той же ставке
Оплачивать вы его можете как угодно. Вы их учитываете как задачи? Любые совещания? Вообще любые вещи, которые не относятся конкретно к работой над задачей?
По тому, который будет выполнять эту задачу.
Но вы не знаете заранее кто её будет выполнять на самом деле.
gun_dose
04.12.2024 12:30Если совещание большое, оно учитывается, как задача. Если это звонок на 5 минут, это всё идёт в рамках текущей задачи. В этом и суть планирования - заложить в эстимэйт время на кофе, поход в туалет, зарядку для глаз, и конечно же, на доработку задачи после возврата от QA. Что такое нормальное планирование? Это когда ты берёшь задачу, оценённую в 5 часов и неспеша, в комфортном для себя темпе делаешь её за 3 часа, а логируешь 4. В итоге менеджмент доволен, что ты управился на час быстрее, а у тебя нарисовался час свободного времени. Если работать в комфортном темпе не выходит, то либо менеджмент занижает трудозатраты, либо ты не подходишь для этой работы. Но как правило, чаще вина менеджмента.
Но вы не знаете заранее кто её будет выполнять на самом деле.
Ну приехали. Это где это так планируют задачи из расчёта, что их будет делать непонятно кто? Пока задача в бэклоге, да, предсказать бывает трудно. Но если ты её берёшь в спринт, то у тебя на этот момент уже должна быть сформирована команда с определённым капасити. На самом деле не обязательно эстимэйт заточен под конкретную личность. Как правило во время планирования рассуждают с позиции "отдадим задачу одному из вот этих трёх чуваков, у которых приблизительно одинаковый перформанс". А если тебе приходится во время спринта передавать джуновскую задачу сеньору, это уже форс-мажор, причиной которого является плохое планирование.
Kanut
04.12.2024 12:30Если совещание большое, оно учитывается, как задача. Если это звонок на 5 минут, это всё идёт в рамках текущей задачи.
А если небольшое, но их много? Кто и как учитывает эти часы? Кто и как учитывает "сходил в туалет" или "пошёл взять кофе" или "начальник задержал на пол часа"?
В итоге менеджмент доволен, что ты управился на час быстрее, а у тебя нарисовался час свободного времени.
В итоге менеджмент перестаёт тебе доверять и всегда ожидает что задача будет сделана на два часа раньше.
Это где это так планируют задачи из расчёта, что их будет делать непонятно кто? Пока задача в бэклоге, да, предсказать бывает трудно. Но если ты её берёшь в спринт, то у тебя на этот момент уже должна быть сформирована команда с определённым капасити.
Что такое "капасити" и как вы его посчитали? Почему нельзя посчитать это капасити для команды в целом?
Что вы будете делать если кто-то справился со своей задачей быстрее чем ожидалось , а кто-то наоборот?
gun_dose
04.12.2024 12:30Кто и как учитывает "сходил в туалет" или "пошёл взять кофе" или "начальник задержал на пол часа"?
Начал делать задачу в 9:00. В 9:15 отлучился на 10 минут за кофе. В 9:50 отлучился на 5 минут в туалет. Закончил задачу в 11:00. Логирую два часа. Что тут непонятного?
всегда ожидает что задача будет сделана на два часа раньше.
Менеджмент должен думать, что я сделал задачу на час быстрее, а не на 2. На самом деле, если бы я всегда логировал именно столько времени, сколько затратил, меня бы уже уволили, потому что у клиента не хватило бы на меня задач.
Что такое "капасити" и как вы его посчитали? Почему нельзя посчитать это капасити для команды в целом?
Capacity - ёмкость. Считается по формуле N * 40, где N - число участников команды. А 40 - число часов в неделе. Например, если у тебя 5 человек в команде, то капасити 200 часов в неделю. Если на среду забукан звонок на час с участием трёх человек, то капасити уже 197 часов.
Что вы будете делать если кто-то справился со своей задачей быстрее чем ожидалось , а кто-то наоборот?
Ну что за глупые вопросы? Если один сидит без задач, а второй не справляется, значит надо отдать часть задач того, кто не справляется, тому, кто без задач. Неужели это непонятно. Если же все задачи сделаны, а время осталось - сиди решай техдолг. Но в любом случае суть проджект-менеджмента сводится к тому, чтобы такого не было. У программиста цель писать софт без багов. У ПМ цель всегда укладываться в сроки. У сантехника цель, чтобы трубы не протекали. Но по факту всегда будут и баги и сорванные сроки и сорванные краны, потому что такова жизнь. И в любой профессии качество специалиста измеряется процентом факапов.
Kanut
04.12.2024 12:30Начал делать задачу в 9:00. В 9:15 отлучился на 10 минут за кофе. В 9:50 отлучился на 5 минут в туалет. Закончил задачу в 11:00. Логирую два часа. Что тут непонятного?
Так речь то не о логировании, а о планировании.
Менеджмент должен думать, что я сделал задачу на час быстрее, а не на 2.
И там конечно одни дураки сидят.
Capacity - ёмкость. Считается по формуле N * 40, где N - число участников команды
Каким образом это поможет при планировании а вашей системе если здесь не учитываетсяс какой скоростью решает задачи каждый отдельный её член?
Если один сидит без задач, а второй не справляется, значит надо отдать часть задач того, кто не справляется, тому, кто без задач.
То есть получается что вы не можете запланировать кто конкретно будет решать какие задачи в спринте. О чем и речь.
gun_dose
04.12.2024 12:30Так речь то не о логировании, а о планировании.
По залогированному времени в ретроспективе определяется точность планирования, и все будущие планы всегда строятся на основе предыдущего логирования. Отсутствие логирования = отсутствие учёта. Опять же, если мне дадут на оценку задачу, а я делал похожую задачу месяц назад и залогировал 2 часа вместе с кофе и туалетом, это значит, что в этот раз она займёт всё те же 2 часа, и с большой долей вероятности, я снова отлучусь и за кофе, и в туалет.
И там конечно одни дураки сидят.
Если менеджмент не обвешивает сотрудников трекерами активности и видеонаблюдением, это не значит, что они дураки.
Каким образом это поможет при планировании а вашей системе если здесь не учитываетсяс какой скоростью решает задачи каждый отдельный её член?
Таким, что при более тщательной оценке капасити распадается, к примеру, на 40 джуновских часов, 120 мидловских и 40 сеньорских.
То есть получается что вы не можете запланировать кто конкретно будет решать какие задачи в спринте.
Нет, нет, и ещё раз нет. ПМ может планировать, кто будет делать какую конкретную задачу и он делает это. И в итоге большинство задач должно следовать плану. Ситуация с передачей задач от одного исполнителя другому, как правило возникает в конце спринта, что объясняется тем, что никакое планирование не является на 100% точным. Степень точности планирования, определённая в ретроспективе - это и есть показатель качества работы менеджмента.
Получается так, что планирование - это сложно, плюс планирование никогда не будет на 100% точным. Но если это сложно, это не повод от этого отказываться.
BoldDwarf
04.12.2024 12:30А еще там не учитываются компетенции разных членов команды.
По замыслу все разработчики там подобно роботам - все одинаковые, с одинаковыми скилами и решают задачи с одной скоростью.
Жизнь обычно несколько сложнее схем.
onets
04.12.2024 12:30Да, я однажды поделил сумму сторипоинтов на сумму отмеченных часов в жире. Получилось 1sp = 8ч. Это разумеется для конкретной команды и проекта.
1sp - это, насколько я помню, была задача по добавлению поля на форму или в грид. Без бизнес логики, просто crud.
lamerok
04.12.2024 12:30Думаю, что планирование приблизительное (пальцем в небо - типа я так вижу на данном этапе) - оно конечно в часах, потому что это надо действительно для оценки стоимости проекта.
Другое дело, что в реальности эти часы, просто часы для бухгалтера и инвестиционного комитета, который решать давать деньги или нет.
И в реальности логично оперировать попугаями, как в скраме, мол эта фича на 10 попугаев, а эта на 2. Создали полный список фич, просуммировали попугаи (получили скажем 100500), потом посмотрели, ага от нас хотят, чтобы мы сделали проект за 10 месяцев. Значит надо 10 спринтов по 1005 попугаев.
Стали делать первый спринт - получилось скорость 5025 попугаев, получается вместо 10 месяцев будем делать 20. Идем на комитет, рассказываем, что вместо 10 месяцев будем этой командой делать 20 месяцев.
Комитет уже решает, либо соглашается, ок делайте 20 месяцев, либо говорит давайте в два раза больше народу нагоним, а если денег нет, то разгоняем команду и закрываем проект.
LoshadkaNaRabote
04.12.2024 12:30Поделюсь своим скромным опытом наблюдения за командой: рп, разраб, аналитик и куча еще всякого народа. На совещаниях человек по 6-7. По итогу, низкий КПД, команда год проедала деньги и всех разогнали. Это, конечно, частный случай и не дает нам практику, но за этот год они попробовали много схем борьбы с атомизацией, включенностью команды, дошли до того, что пол дня занимали совещания. Оплата стояла почасовка с учетом работы над задачей, но, пользуясь этой дырой (тем, что никто никогда не знает, сколько в реальности это займет времени) команда просто ела деньги заказчика.
IvanBodhidharma
04.12.2024 12:30за этот год они попробовали много схем борьбы с атомизацией, включенностью команды, дошли до того, что пол дня занимали совещания.
А работать они пробовали?
пользуясь этой дырой (тем, что никто никогда не знает, сколько в реальности это займет времени) команда просто ела деньги заказчика.
Тимлид был в команде (настоящий, не трёхлетний)?
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 оценок: первая на то, чтобы собрать общую инфу о проблеме и существующих подходах/решениях. И эта первая оценка обычно просто фиксированная, в зависимости от объёма и/или новизны данных, обычно день или два. И вот сколько данных успеешь собрать за это время - с теми и работаешь. Вторая оценка даётся по результатам инфы собранной на предыдущем этапе и она уже будет намного более точной. Обычно двух оценок хватает, но изредка сбор данных на первом этапе показывает только то, что нужно ещё неделю продолжать собирать данные (т.е. продлить первый этап), и без этого двигаться дальше нет смысла - тогда либо задачу отменяют вообще либо мы второй оценкой получаем эту самую неделю, а через неделю сможем уже оценить сколько времени нужно на решение задачи.
IvanBodhidharma
04.12.2024 12:30Что делать известно, неизвестно как и какие грабли будут по дороге. А бизнес просит оценку сегодня. Вот и приходится использовать метод ППП и чуйку.
powerman
04.12.2024 12:30Про грабли неизвестно никогда, в любых задачах кроме типовых (а типовых в нашей работе обычно намного меньше нетиповых).
А "неизвестно как" - это как раз и есть причина давать оценку итеративно, по мере роста понимания "как".
Если бизнес этого не понимает/принимает, и предпочитает иметь оценку "с потолка" вместо более адекватной - тут есть разные варианты, в зависимости от того, зачем бизнесу нужна эта оценка. Если она бизнесу нужна для принятия стратегических решений вроде "браться ли вообще за этот проект" или "какую цену выставить клиенту за этот проект", то оценка "с потолка" выполненная кем-то достаточно опытным вполне подойдёт. В дальнейшем могут потребоваться дополнительные усилия (вроде урезания фич, реализации быстро-грязно хаков или переработок) чтобы в неё вписаться и проект не стал для бизнеса убыточным. А если она бизнесу нужна с целью увеличения контроля над разработчиками и микро-менеджмента "почему задачу на 5 часов делали целых 7?!", то нужно либо завышать все оценки раза в 3 либо менять работу.
Tirarex
04.12.2024 12:302) Исследовательские задачи можно достаточно легко оценивать, просто это будет не одна оценка а последовательность из 2-3-4 оценок: первая на то, чтобы собрать общую инфу о проблеме и существующих подходах/решениях. И эта первая оценка обычно просто фиксированная, в зависимости от объёма и/или новизны данных, обычно день или два. И вот сколько данных успеешь собрать за это время - с теми и работаешь.
За 2 дня собрал инфы на решение которое потребует месяц реализации на алгоритм.
За 4 дня собрал инфу с готовым алгоритмом который решает задачу за 2 дня c тестами.
По опыту говорю что такое реально бывает.
powerman
04.12.2024 12:30Бывает, знаю. Тем не менее, лучшего подхода пока нет, а этот работает достаточно хорошо (хоть и иногда вот с такими сюрпризами, да).
Tirarex
04.12.2024 12:30В одном проекте начинали как раз с этого подхода с узкими рамками на рисерч. В итоге было выбрано как казалось лучшее полуготовое решение (за неимением времени на продолжение рисерча), в краткосрочной перспективе задача закрыта, в долгосрочной перспективе я уже ушел с проекта давно, а на всем его протяжении то решение давало кучу проблем выливающихся в огромные косты бизнесу и не лучшую производительность софта.
В данный момент насколько мне известно, то решение не заменено из за слишком большой завязки на него. 2 дня сэкономили сегодня - месяцы рабочего времени слиты в унитаз на багфиксы и подпил под нее, а софт работает не так хорошо как мог (если бы было потрачено 1-2 недели на самописное решение с рисерчем), и многий функционал не может быть реализован из за этого решения. Менять его категорически нехотели так как уже влили в его поддержку кучу денег.
В итоге на моей памяти, узкие временные рамки на ресерч в итоге ни разу не работали в плюс. Калька выше из геймдева, возможно в ваших краях все по другому.
powerman
04.12.2024 12:30Да, бывает и такое. А ещё вполне вероятно, что "самописное решение" принесло бы ещё больше проблем в долгосрочной перспективе - и адекватно оценить вероятность такого исхода крайне сложно.
Недостатки есть у всех подходов, а серебряной пули нет. Критикуя - предлагайте другой подход, который Вы считаете более подходящим. Вариант "рисёрчим до упора сколько бы это ни заняло" уже многократно проверен на практике и признан неприемлемым для абсолютного большинства проектов (где сроки и цена имеют значение для бизнеса). Другие предложения есть? На практике их уже проверяли?
Tirarex
04.12.2024 12:30Да, бывает и такое. А ещё вполне вероятно, что "самописное решение" принесло бы ещё больше проблем в долгосрочной перспективе - и адекватно оценить вероятность такого исхода крайне сложно.
Не " вполне вероятно" а совсем наоборот, самописное решение требовало монотонной работы, но его результат был бы надежный как автомат Калашникова, так как он использовал более простой подход влоб и не тянул зависимостей. (От части его в итоге реализовали, но время на его интеграцию не давали со словами "мы на то старое решение уже Х потратили и на новое ничего тратить не будем, у нас ничего нет!", при том тестовое решение было во всем лучше.
Недостатки есть у всех подходов, а серебряной пули нет. Критикуя - предлагайте другой подход, который Вы считаете более подходящим.
Истина посередине. не давать какие то малые/сжатые сроки на рисерч, но при этом не давать картбланш на недели/месяцы, и уж тем более не соваться в воду не зная броду, те не пытаться оценивать время рисерча, пока его исполнител/ли не открыли гугл и не провели уже что то базовое дабы понимать отдаленные сроки и сложность.
powerman
04.12.2024 12:30А где я предлагал "оценивать время рисерча, пока его исполнител/ли не открыли гугл" или "давать какие то малые/сжатые сроки на рисерч"? Я говорил о том, что вместо выдачи задачи на рисёрч с открытыми сроками нужно поделить её на этапы, и устанавливать срок на следующий этап по результатам предыдущего.
Т.е. вместо того, чтобы отправить разработчика гуглить без каких-либо сроков ему выдаётся на это два дня. Через два дня он должен быть в состоянии либо выдать результаты и прогноз сроков на следующий этап (которым может быть уже не гугл всего подряд по теме, а более глубокое исследование/сравнение двух-трёх найденных на первом этапе решений/подходов), либо сообщить что прогресса за эти два дня нет и мы по-прежнему не имеем вообще никакой конкретики. В последнем случае ему либо выдаётся ещё пара дней, либо задача передаётся кому-то более квалифицированному, либо задача возвращается в бэклог (с планами вернуться к ней когда-нибудь в будущем).
При таком подходе у бизнеса есть контроль над сроками. Время выделяемое на исследование может при этом быть сколь угодно большим, но оно выделяется небольшими итерациями, и бизнес может контролировать соотношение прогресса исследования и затрат времени, с возможностью отменить задачу после любой итерации либо принять решение использовать текущие результаты исследования (возможно не финальные-идеальные, но считающиеся good enough).
Tirarex
04.12.2024 12:30Зачастую рисерч просто так на этапы не поделить, бывает black box и на выходе когда то что то будет, а может времени не хватило, и не будет, и этапов нет, оно пока либо совсем никак не работает, а может быть завтра заработает.
Кроме того, подход с дроблением вносит бюрократию, много бюрократии... В вебе можно забить на это и тратить часы впустую на очередные отчеты дейлики и жиру, но работая с +-идейными/скиловыми людьми, они быстро выгорят от бесконечных очередных созвонов и вытягивания речей почему надо на рисерч еще и еще время. Звучит смешно но я знаю уйму поистине талантливых людей которые бежали от менеджмента бизнеса. Сроки, канбан и менеджмент это давление как ни крути, и под ним идейные и талантливые люди редко выживают, а те что остались, не часто решают проблемы.
Вот и выходит что бизнес думает что имеет контроль и сроки, а на деле там программисты кидают d4, и бизнес получает шанс реализовать фичу либо вообще никак, либо плохо, либо хорошо если повезет. И если в вебе есть тысяча фреймворков и отрисовать кнопку плохо это сложная задача, то в том же геймдеве что ни задача то очередной рисерч на N недель, и если бизнес хочет решенную задачу и хорошо, то он ждет сколько надо, а если не ждет то и задача не решается, а в таком раскладе без бюрократии и сроков - банально быстрее и проще.
powerman
04.12.2024 12:30Не-а. На этапы поделить можно всегда.
Если разработчик не может на этапы поделить и рассказывает "когда то что то будет, а может и не будет" то это называется недостаточная квалификация и никаких важных/сложных ресёрчей ему пока поручать нельзя (можно только простые/не критичные, чтобы он учился делать ресёрчи).
Эта бюрократия называется рабочий процесс, и без неё, к сожалению, будет ещё хуже - разработчики уйдут в себя, будут что-то делать, но что именно и когда оно будет готово не будет знать никто, включая самих разработчиков. Так уже работали, много работали, и пришли к выводу что ничем хорошим (для проекта и бизнеса) это не заканчивается, после чего и появилась вся эта бюрократия.
Бесконечные созвоны - это когда в компании не умеют ни в процессы/бюрократию ни в разработку. Обычно часового созвона раз в неделю для синхронизации между командами плюс нерегулярных созвонов внутри команды исключительно по необходимости и часто 1-на-1 - хватает. И никто от такого не выгорает.
Талантливым и идейным обычно это все мешает не настолько критично. А вот любителям развести на проекте удобный только лично им бардак и хаос, плюс ненавидящим любую форму контроля над ними - да, критично. Но такие и пусть бегут - от них обычно всё-равно никаких предсказуемых результатов получить не удаётся, работать в команде они не умеют, а те "гениальные" проекты, которые они способны реализовать самостоятельно в наши дни не особо интересны, потому что во-первых они очень маленькие и во-вторых их может поддерживать и развивать только их автор - и какими бы реально классными эти проекты ни были эти организационные недостатки перевешивают все плюсы. Поэтому желающих оплачивать этим талантам их разработки обычно не находится, и им остаётся только писать эти проекты за свой счёт и выкладывать на гитхаб.
Tirarex
04.12.2024 12:30ЕслАи разработчик не может на этапы поделить и рассказывает "когда то что то будет, а может и не будет" то это называется недостаточная квалификация и никаких важных/сложных ресёрчей ему пока поручать нельзя (можно только простые/не критичные, чтобы он учился делать ресёрчи).
Еще раз напомню про геймдев в моих примерах. В вебе в котором вы можете работать, да квалификация, а в геймдеве особенно в сложных направлениях, все примерно как в науке или медицине. Что то исследовано, но 99% не исследовано, и можно нанимать лучших прогеров мира, но они так и будут говорить что задача займет от часа и до полугода, +-.
Эта бюрократия называется рабочий процесс, и без неё, к сожалению, будет ещё хуже - разработчики уйдут в себя, будут что-то делать, но что именно и когда оно будет готово не будет знать никто, включая самих разработчиков. Так уже работали, много работали, и пришли к выводу что ничем хорошим (для проекта и бизнеса) это не заканчивается, после чего и появилась вся эта бюрократия.
Да работали, и ввели бюрократию, и к чему же оно привело в геймдеве? Day 0 патчи, провальные релизы, абсолютно постные AAA игры с реюзом технологий и ассетов (рисерчи не надо делать если ты взял весь хлам со с прошлого проекта, привет асасинам, фаркраям, fifa и еще целому списку игр.) Да масштабы выросли, но не только игр, но и проблем в играх. Инди сцена сейчас на взлете.
Талантливым и идейным обычно это все мешает не настолько критично.
Я лично знаю несколько людей которые работали в крупнейших студиях (и не в рф в том числе) и успешно сбежали с этих студий банально из за бюрократии, созвонов и тасков с оценками. При том некоторые имеют очень успешные личные проекты, которые буквально кормят их пока они сидят на диване и изучают новые технологии и варианты решения интересных им задач.
Но такие и пусть бегут - от них обычно всё-равно никаких предсказуемых результатов получить не удаётся, работать в команде они не умеют,
А вот и мой пример =) написанные мною техники с долгим рисерчем, работают без каких либо проблем. никаких других вариантов у того работодателя нет, все что они сами делали работает хуже и дает не такой качественный результат. Вот такой вот убежал, за забором никаких очередей не оказалась, дорабатывать настолько сложные и масштабные техники некому, написать с нуля те же зазаборные их не могут, а возвращаться в эту духоту даже по верху рынка желания нет.
Добро пожаловать в геймдев, тут вам не рисерч на перекрас кнопки и смену порта докер контейнера, тут приходится реально работать.
powerman
04.12.2024 12:30Я действительно не работал в геймдеве. В плане игр я обычный пользователь. И я полностью согласен про "постность" многих AAA и взлёт инди. Но я крайне скептично отношусь к идее, что в этом виноваты обычные процессы разработки, которые работают во всех остальных сферах.
dimaaannn
04.12.2024 12:30Логика "эффективного" менеджера )
Если задача неизвестна - создаём задачу-прототип, а с непонятками разберёмся позднее.
А если прототип уже сделан - значит тут и так всё понятно, просто немного доделать и в продакшен
powerman
04.12.2024 12:30Не, "эффективные" менеджеры - это про другое, и там всё намного-намного хуже.
Первое действительно норм. Бизнес довольно часто сам не знает, чего он хочет - просто потому, что это всё вообще "хочет" не он, а ЦА, а что именно хочет ЦА выяснить без прототипа невозможно (ну или просто непонятно как либо ещё дороже чем прототип сделать). Поэтому делаем прототип, даём пощупать ЦА, получаем обратную связь, и повторяем.
А вот второе - это реально беда, согласен! Когда бизнес воспринимает прототип как что-то рабочее, что можно в прод… А он почти всегда воспринимает именно так. Я для себя нашёл "выход" из этого порочного круга в том, что я даже прототипы не пишу быстро-грязно. Да, где-то какие-то углы и крайние случаи в прототипе срезаются, но даже в таких местах я предпочитаю чтобы сервис громко упал или хотя бы отрепортил метрику (которая обязательно приведёт к алерту) если такой "нереализованный" случай всё-таки произойдёт. Приходится искать баланс между тем, что, с одной стороны, это вроде как прототип и "вылизывать" его смысла нет потому что этот функционал может быть выкинут/заменён, а с другой стороны этот прототип в любой момент может оказаться основным продакшном на долгие годы. В общем, делаю всё возможное, чтобы даже прототипы было легко поддерживать и развивать, стараясь жертвовать какими-то другими характеристиками ради скорости разработки но не этой. Если такой возможности нет и какую-то часть всё-равно (другие команды) напишут быстро-грязно - я стараюсь её хотя бы изолировать максимально.
redfoxxy12
04.12.2024 12:30> Вот по этому и такая разница в зарплате
А курьер почему больше профессора получает? Потому что постоянно учит новые маршруты на райончике получается?
Бизнесу глубоко плевать учитесь вы или не учитесь если задача выполняется. Так получилось что сейчас цифровые сервисы приносят бизнесу огромные деньги, а для их создания нужны программисты. Вот и все. Которые еще и работать на зарубеж могут через Интернет, в отличие от скажем инженеров. И соответственно бустить тем самым планку зарплат.
Специальностей, в которых надо постоянно изучать что-то новое, достаточно. Та же медицина. И учить там надо намного больше информации, чем фронтэндеру.
kozel_rogatiy
04.12.2024 12:30Та же медицина. И учить там надо намного больше информации, чем фронтэндеру.
Всё это учится на этапе обучения. Далее если что-то новое и появляется/внедряется, то проходят годы исследований и согласований. Всё это давно изучено, давно описано и ничего кардинально нового там не появляется.
Хватит уже рассказывать байки про то, как много учатся в других областях. Я прихожу к взрослой-тетке терапевту в поликлинику с ярко выраженной болью в органах, в определенном месте, а она мне выписывает анальгин и не в состоянии даже предположить, что та может болеть. Учатся они, плять. Нихрена они там не учатся.
Атишка - самая мозговыносящая сфера, где среднечковый мидл по объему знаний и трудозатрат тянет на компетенцию профессора.
redfoxxy12
04.12.2024 12:30> а она мне выписывает анальгин и не в состоянии даже предположить, что та может болеть
Плохой или выгоревший специалист запросто может работать в любой сфере. IT не исключение. Людей, которые только вредят, или в лучшем случае выполняют задачу с которой справится уборщица, за неадекватные для такого труда деньги, везде хватает.> то проходят годы исследований и согласований
К примеру в последнее десятилетие полностью поменялась концепция лечения гепатита С, достаточно распространенной болезни. Если раньше это было дорого, долго и без надежного результата, то теперь это в подавляющем большинстве случаев сводится к подбору не очень дорогого препарата. Врачи тут же поделились на тех, кто изучает новое самостоятельно и в курсе современных концепций лечения, и тех кому в 90м году говорили что гепатит С фактически неизлечим. При этом первые еще и вставали перед моральной дилеммой - лечить пациента по устаревшей официальной концепции, или же рассказать ему где можно купить необходимый для лечения современный препарат до того, как он получил разрешение местных властей (что часто занимает годы).
Ну можно сказать подумаешь, сложно что ли это запомнить. Но ведь врачу общей практики надо держать в голове далеко не один десяток заболеваний. Нужно быть в курсе, например, что болезни тоже мигрируют, и заболевания, бывшие в вашем городе исключительно редкими 20 лет назад, сейчас встречаются уже на порядки чаще, в следствие возросшего туризма с последующим заносом нехарактерных для региона заболеваний, и изменений климата.
sobeskiller
04.12.2024 12:30К примеру в последнее десятилетие полностью поменялась концепция лечения гепатита С
Десятилетие, Карл! И ещё пару десятилетий она будет жить и применяться. Сравните с айти, где каждый год появляется очередная старая-"новая" срань, досконально разбираться в которой ты просто обязан если хочешь оставаться на плаву на рынке труда. Т.е. можешь конечно и дальше пилить проект например на Java 15, и он даже отлично будет работать. Но фактически ты уже нетрудоустраиваем на современном рынке.
Kanut
04.12.2024 12:30За последние двадцать-двадцать пять лет появилось несколько новых вариантов лечения кератоконуса. А в старых поменялись медикаменты, инструменты, подходы.
И это одна единственная болезнь. А если взять все вещи, которыми занимается окулист?
А если учесть влияние других органов и/или болезней на глаза?
sobeskiller
04.12.2024 12:30За последние двадцать-двадцать пять лет появилось
Божемой! В айти за последние 20-25 лет проще по пальцам перечислить что осталось, чем появилось! Что тут спорить, айтишнику приходится переучиваться гораздо интенсивнее чем врачу. Притом такой "отставший" врач работу всё равно найдёт. Айтишник - чуток отстал на текущей работе - и уже серьёзные проблемы с трудоустройством!
А если взять все вещи, которыми занимается окулист?
Отличное замечание! Окулист! Этот окулист случайно внагрузку не стал ещё заниматься проблемами ЖКТ и опорно-двигательного аппарата? В айти - стали! К бэкенду фронтенд. А теперь ещё и девопсинг.
Правильно выше сказали. Трудозатраты в современном айти просто не оправдывают таких денег которые платят. Исключения конечно есть когда кому-то где-то удалось затесаться и на чиле не париться... До ближайшего увольнения-сокращения...
Kanut
04.12.2024 12:30В айти за последние 20-25 лет проще по пальцам перечислить что осталось, чем появилось
Ну расскажите например что нового появилось у людей, которые пишут на коболе.
При этом не забывайте что я написал про одну единственную болезнь. Сколько их всего у окулиста.
Айтишник - чуток отстал на текущей работе - и уже серьёзные проблемы с трудоустройством!
Какие проблемы, вы о чём? Легаси много где надо пилить. Ну задачи будут скучные, ну зарплата не такая высокая. Ну так и врача примерно то же самое.
! Окулист! Этот окулист случайно внагрузку не стал ещё заниматься проблемами ЖКТ и опорно-двигательного аппарата?
Так вот именно что стал. То есть например есть Uveitis. Очень неприятная штука. Проявляется на глазах. Причины могут быть где угодно в организме. И таких болезней тоже не мало.
Трудозатраты в современном айти просто не оправдывают таких денег которые платят.
Вы вообще о чём? Подавляющее большинство знакомых мне айтишников тратят на работу ровно свои 40 часов в неделю. А то и меньше. Никаких пет-проектов. Никакого обучения вне рабочего времени и уж тем более за свой счёт. Какие у них трудозатраты?
SpiderEkb
04.12.2024 12:30Какие проблемы, вы о чём? Легаси много где надо пилить. Ну задачи будут скучные, ну зарплата не такая высокая.
Ну тут можно поспорить по всем пунктам.
"Пилить легаси" (и что вы понимаете под легаси) часто заключается в том, чтобы понять как оно работает и оптимизировать. При этом не порушив ничего вокруг. Это очень нетривиальная задача и совершенно не скучная.
Легаси много в банках. Причем, реального легаси - банки живут по принципу "работает - не трогай" и если потребовалось этот легаси пилить, значит на то есть очень веские причины (обычно это оптимизация, иногда - изменение бизнес-логики). А с деньгами там, в отличии от того же геймдева, к примеру, все не так плохо - в свете последних "событий" з/п не только не уменьшились, но и увеличились (бывает что кратно) и продолжают стабильно расти.
Ну и ничего страшного в легаси не вижу если честно.
Kanut
04.12.2024 12:30Ну тут можно поспорить по всем пунктам.
Вы не по тем пунктам спорите. Речь о том что если всё время только пилишь легаси, то количество новых вещей, которые надо учить, достаточно обозримо.
В условном коболе за последние 25 лет мало что изменилось. Тем более вот так чтобы совсем принципиально. Однозначно не больше чем в офтальмологии.
П.С. А деньги да, их и в случае с легаси иногда неплохо платят. В отдельных случаях даже совсем неплохо. Но в среднем за легаси платят меньше. По крайней мере у нас.
rdo
04.12.2024 12:30Абсолютно ничего не поменяется. Разработик на Java 15 просто за пару часов прочитает, какие вопросы задают по актуальным версиям JVM и получит оффер. Вот если он последние 10 лет пилил монолит на Java 8 и не слышал ничего о микросервисах, то тогда да, с трудоустройством могут возникнуть проблемы.
myswordishatred
04.12.2024 12:30Ну, знаете, так можно сказать "Прихожу я к проргаммисту, а он пузырьком сортировать не умеет, нихрена они там не учатся". Составление статистики по одному случаю это процесс увлекательный, конечно, но не очень полезный.
WindMill
04.12.2024 12:30Я делаю так: даю задание, спрашиваю про сроки. Начинают закатывать глаза, говорить что-то типа "нуууу, к лету в лучшем случае сделаем и то не факт". Беру аутсорс. 6 часов и готово. Урезаю премии. Опять даю задание. Глаза уже не закатывают, говорят "нууу, пару дней". Окей, работаем.
Quackerjack
04.12.2024 12:30Аутсорс - фигак-фигак и в прод заказчику. А дальше, случись чего мозговыносящие, две двери - костыли или "ящерицын хвост" + чернильное облако. Иногда, это поделие так и живет годами и все думаю. - "Почему так перестраховывалась?", но чаще, тем парням кто на галере с Вами, надо закладываться под масштабирование, поддержку и качественную конвертацию накопленных данных - им с этим жить, потому и перестраховываются. Истина - посередине +/- эпсилон умноженное на коэффициент выгорания мидлов.
WindMill
04.12.2024 12:30Ждал таких комментариев. Аутсорс плохо, ИИ вообще зло и только вонючие бородатые недооцененные и непонятые никем смузихлебы это тру. Причем, что удивительно, чем больше сеньоров и всяких умных тимлидов (а лучше еще пару продакт овнеров конечно), тем, внезапно, сложнее и больше разработка. А потом еще и выясняется, что, опять внезапно конечно, но все равно: "костыли" + "монолит" + "нету документации". Ну-ну. Ага.
Quackerjack
04.12.2024 12:30ИИ отлично занял свою нишу помощника в мелких задачах и скетчей для задач среднего уровня и анализа данных, он инструмент. И как бы вы недолюбливали «смузихлебов», «пасти» и пользоваться ИИ будут они, пока менее шапкозакидаательный ПМ пасет их. Остальное, пока - влажные мечты СЕО с мягким мозгом и акционеров ИТ-компаний, которым они их транслируют и которые играют в рынок финансового капитала, им в целом пофиг на средства производства ИТ и они в них не шарят.
Аутсорс -тоже отличный инструмент, к месту. Но шантажировать им коллектив и демпинговать сроки, так себе идея. Если у вас уж совсем нет доверия коллективу, сделайте совместный разбор предыдущих затяжных задач, думаю все станет ясно.
IvanBodhidharma
04.12.2024 12:30Используйте чат гопоты, зачем платить за аутсорс? И вообще, завтра контрольная по математике, судя по тому, что вы пишите. Если лиду говорят "пол года" про задачу, которая решается за 6 часов и он вынужден нанимать аутсорс, чтобы понять, что ему втирают дичь, то такому лиду надо выдать грандиозный подсрачник с волчьим билетом и татуировкой на лбу: "сей балбес в ИТ не способен".
powerman
04.12.2024 12:30Просто @WindMillописал вполне рабочий подход который используют проджект/продакт-менеджеры, у которых нет IT-специфичного опыта но есть общий опыт менеджмента, и которым нужно управлять командой мидл-разработчиков без нормального тимлида. Такое встречается не так и редко, особенно в небольших стартапах. Да, это не очень эффективный подход, но для другого нужны более квалифицированные кадры, которые не всегда есть возможность нанять.
QweLoremIpsum
04.12.2024 12:30У нас был похожий пример, дан поиск на сайте, пагинация и тд, надо исключить из поиска результаты по такому то критерию.
Аутсорсер вместо того чтобы подумать и исправить запрос к поисковому движку, решил просто через цикл исключить результаты из каждой страницы результатов... То, что некоторые страницы вместо 10 результатов стали выдавать 2-7, а некоторые вообще пустые - пм не заметил и принял работу. Спохватились только когда первая страница стала пустой...
Скупой платит дважды
qeeveex
04.12.2024 12:30у нас аутсорсер зафигачил в onclick каждой торговой позиции тело js функции которое через jquery инкриментировало корзину и делало ajax запрос на отдельный php файл.
Politura
04.12.2024 12:30Программисты хитрые, они не говорят "Мы не знаем, когда сделаем задачу", они говорят "AGILE". Существует два распространенных подхода к оценке задач в условиях неопределенности.
За 20+ лет в профессиональной разработке ни разу не слышал, чтоб кто-то на вопрос о сроках отвечал аджайл, всегда называли конкретные сроки и всегда задачам ставилась дата релиза. Разница лишь в том, что опытные в оценке команды и лиды чаще всего укладываются в назначенные сроки, неопытные в оценке очень часто не укладываются. Но если у неопытной команды опытный менеджер, он накинет время сверху и все будет нормально. :)
shushara4241
04.12.2024 12:30Неправильная оценка задач - это когнитивная ошибка (ошибка планирования) и к сожалению ей подвержены все, даже опытные специалисты. Единственный вариант - закладывать сроки, в которые с шансом 80-90% уложишься
pavelsha
04.12.2024 12:30Давайте будем честными... Содержание статьи вторично. Пока читал, начал жалеть, что кармы не хватит минусить её. Но имеет смысл простить за блок советов в конце.
Главные навыки - способность быстро учиться новому и эффективно взаимодействовать с командой.
Если чего-то не знаешь - это нормально, спроси.
Если не успеваешь к срокам, о которых договорились, это нормально, главное скажи об этом как можно раньше, и подсвети что не учли при оценке.
А если ты только в поисках первой работы, не пробуй выучить все, иди на собеседование, возможно ты уже знаешь достаточно.
vis_inet
04.12.2024 12:30Вот вы написали комментарий с вашим отношением к статье и выводами.
Это гораздо полезнее, чем вы просто заминусили бы её.
IvanBodhidharma
04.12.2024 12:30Представь, что ты решил стать программистом на Java.
Или водителем Шкоды...
Есть одна вещь, без которой невозможно программировать (помимо компьютера конечно), — это интернет. Отключи программисту доступ в сеть — и с вероятностью 90% он не напишет даже простое веб-приложение.
Чушь какая. Да, он не напишет всё это на модных фреймворках, но базовые вещи типа http, html, js, любой серверный язык и всё будет написано. Конечно, пару бумажных справочников иметь необходимо при этом, т.к. всего, действительно, не упомнишь.
А как установить сроки?
Тут нейросеть бредила, комментарии излишни.
как выбрать самый важный?
Язык, это инструмент, а не самый важный курица. Подите прочь из отрасли, мудаки тупорылые. Дальше не читал.
Source
04.12.2024 12:30Конечно, пару бумажных справочников иметь необходимо при этом
Зачем бумажных то? Сейчас почти все ЯП и фреймворки идут со встроенной документацией. Открывай локально её в браузере и пользуйся спокойно без интернета.
IvanBodhidharma
04.12.2024 12:30Зачем бумажных то?
Мне нравятся бумажные. И речь была про базовые вещи типа http.
LaRN
04.12.2024 12:30Вот интересно, а где в России используется в банках cobol. Я вот все время с банками работаю уже 15+ лет и cobola нигде ее видел. Есть какой-то продукт может который на cobol?
dsvdev Автор
04.12.2024 12:30В России онлайн банкинг начал развиваться относительно недавно, и поэтому сразу на современных языках, COBOL - это скорее про Европу/Америку
alexey_public
04.12.2024 12:30В Росси есть свой банковский Cobol - паскаль, точнее уже Delphi. До сих пор зовут и предлагают хорошие деньги. Но не настолько чтобы выпасть и индустрии на несколько лет и потом мучаться вопросом - как найти работу.
sfunx
04.12.2024 12:30В России есть 1С, он всем Паскалям/Дельфям COBOL
SpiderEkb
04.12.2024 12:30"Я вам на скажу за всю Одессу...", но что-то мне кажется что на 1С ядро АБС банка на 50млн клиентов не построить... Там ведь не только счета-проводки, но и еще очень много чего... Да и производительность-надежность там мегакритична.
Или есть примеры реальные? Я просто не в курсе...
alexey_public
04.12.2024 12:30Нет. Не дотягивает никак. Для начала он опоздал почти на 10 лет. TurboPascal старше.
Во-вторых 1С это не про нагруженные системы. Это про универсальные системы. Это такой яваскрипт на все случаи жизни. Стильно-молодёжно :-) Но с паскалем это и рядом не стояло.
А вот чистый паскаль - это как раз про высоконагруженные системы с очень малым временем отклика. Сам такое делал, там где 1С подобные системы будут отчёт строить несколько часов, у меня уходило несколько минут, причём большая часть времени - выгрузка сложного по структуре отчёта во много страниц со сложным форматированием в Excel.
А такие вещи, как, например, графическая вёрстка, в 1С вообще нереализуемы простыми способами.
Лучше может быть тот же Паскаль, но со вставками на Си при необходимости ещё бОльшего быстродействия.
Ну и самое главное - при своём хорошем быстродействии Паскаль ещё хорошо себя показал именно в банковских расчётах, за что его в банках и любят. Плюс отсутствие сишных проблем с безопасностью (переполнение буфера и др. атаки).
И вообще обычно это стабильный код, который не падает и работает годами. Поэтому до сих пор ему нет замены в его сфере. Разве CPython и то это лишь намёк.
SpiderEkb
04.12.2024 12:30Ну и самое главное - при своём хорошем быстродействии Паскаль ещё хорошо себя показал именно в банковских расчётах, за что его в банках и любят. Плюс отсутствие сишных проблем с безопасностью (переполнение буфера и др. атаки).
А если к классическому процедурному паскалю добавить нативную поддержку всех типов данных, что есть в БД (дата/время, decimal/numiric) и полную интеграцию с БД (возможность поиска/чтения/записи по индексу, возможность интегрировать SQL выражения непосредственно в код и т.п.), то получите RPG, который я тут уже упоминал.
alexey_public
04.12.2024 12:30Ну вот как раз в Delphi это и имеется. И для работы прямой работы с Oracle тоже есть замечательные компоненты.
SpiderEkb
04.12.2024 12:30Не, это совсем не то :-) Я с VCL работал в Билдере. Рядом не лежало...
Объявили файл (логический файл - определяет порядок доступа (access path) к записям таблицы (физическому файлу)
dcl-f ELM20LF disk(*ext) usage(*input) keyed usropn qualified static;Определили структуру (data structure) "такую же как структура записи в таблице" (все форматы данных БД нативно поддерживаются языком)
dcl-ds dsELM likerec(ELM20LF.ELMPFR: *all);Читаем из таблицы запись для заданного значения ключа в структуру
chain (outaddr: 'D') ELM20LF.ELMPFR dsELM;Если такой записи нет или она есть, но значение поля ELMID не равно значений аналогичного по смыслу поля из другой структуры, ставим флаг (потом он понадобится для всякого разного)
if not %found(ELM20LF) or dsELM.ELMID <> dsECA.ECAELMID; needClr = *on; endif;И никаких компонентов. Все это встроенные срадства языка.
Или вот. Нужно просто проверить наличие записи в таблице для заданного значения индекса. Читать саму запись не нужно - содержимое ее тут не интересует. Только факт наличия.
Пытаемся спозиционироваться в логическом файле на значение ключа
setll (ELM: TES) ELM20LF;И проверяем - встали на точное значение или точного значения нет и встали перед записью со следующим большим значением
newELMID = not %equal(ELM20LF);Флаг принимает значение "истина" если записи с таким ключом нет.
Без чтения это очень быстрая операция.
Хочется SQL? Ради бога
Определяем шаблон структуры куда будем читать выборку
dcl-ds t_dsSettings qualified template; PgmName char(50); LogLevel char(50); LimitT char(50); LimitB char(50); LimitE char(50); end-ds;Определяем массив структур по этому шаблону
dcl-ds dsSettings likeds(t_dsSettings) dim(maxLogLevels) static;Определяем SQL запрос
exec sql declare curECLSettings cursor for select A.EC0VAL, coalesce(B.EC0VAL, 'E'), coalesce(C.EC0VAL, 'D002'), coalesce(D.EC0VAL, 'M001'), coalesce(E.EC0VAL, 'M001') from EC0PF A left join EC0PF B on (B.EC0GRP, B.EC0PRM, B.EC0ACT) = (A.EC0GRP, 'LOGEVT', 'Y') left join EC0PF C on (C.EC0GRP, C.EC0PRM, C.EC0ACT) = (A.EC0GRP, 'LOGDEEPT', 'Y') left join EC0PF D on (D.EC0GRP, D.EC0PRM, D.EC0ACT) = (A.EC0GRP, 'LOGDEEPB', 'Y') left join EC0PF E on (E.EC0GRP, E.EC0PRM, E.EC0ACT) = (A.EC0GRP, 'LOGDEEPE', 'Y') where A.EC0PRM = 'PGMNAME' and A.EC0ACT = 'Y';И читаем сразу maxLogLevels записей в массив структур
exec sql fetch curECLSettings for :maxLogLevels rows into :dsSettings;Все. Опять - никаких компонент. Все средствами языка.
И, это т.н. "статический SQL" План запроса готовится на этапе компиляции, а не в рантайме. Что экономит время в процессе исполнения.
Если надо - есть динамический, там можно строку запроса в рантайме готовить, но там телодвижений чуть побольше и ресурсоэффективность хуже. Стараемся по возможности не использовать, только там, где без этого совсем никак.
При этом язык поддерживает все типы данных, что есть в БД - дата, время, форматы с фиксированной точкой (decimal и numeric) и, естественно, всю арифметику с ними - конвертация даты-времени в другие форматы данных (число, строка) с разными форматами дат - DD-MM-YYYY, YYYY-MM-DD и много прочих разных. И обратно - из строки или числа в дату/время.
Финансовые вычисления вообще все идут только с числами с фиксированной точкой. Есть, в том числе, операции с округлением...
Вот тут делал небольшой обзор языка в современном его виде.
Там еще со структурами можно очень гибко работать...
alexey_public
04.12.2024 12:30Нет. Это совсем не то. Это похоже на FoxPro. Когда то в нём кое-что действительно сделал. Но и всё на этом.
Во-первых всё, что встроено в язык, плохо работает с нормальным сервером БД. Сервер постоянно обновляется, sql постоянно дорабатывается.
ИМХО ни в коем случае нельзя одно перемешивать с другим. Вот типы данных да. Но тут проблем обычно нет.
Запросы только динамические. Всё равно статические без поддержки со стороны ядра СУБД тоже автоматом становятся динамическими.
Во-вторых никакой самодеятельности руками. В коде таких вещей не должно быть в принципе.
Когда у вас сотни таблиц в большой разветвлённой структурой, сотни ГГБ данных, множество операторов и жёсткий realtime - у вас в принципе не будет времени писать такие вещи вручную.
Всё это делается в соответствующих компонентах мышкой, быстро, качественно, надёжно. Вам нужно только подключить запросы на выборку, подключить их к выводу через толковые виузальные компоненты и дальше всё забыть.
Работа должна идти на уровне СУБД, там должны быть вьюшки, там должна быть оптимизация, там должны быть хранимые процедуры и все проверки и там все запросы, написанные вручную или автоматизировано. Приложение должно быть максимально автоматизировано и изолированно, никакой ручной работы.
ALexKud
04.12.2024 12:30Для меня delphi\pascal вообще палочка выручалочка. Я хорошо знаю SQL и в общем уже много сложных приложений с бизнес логикой в БД сделал. Мне не нравится тащить логику на клиента, ну может только по минимуму. Поэтому интерфейсы быстро создаю сам в DELPHI. Использовать WEB в моей области разработки для производства и тестирования железа избыточно, сложно и долго. И главное , все десктопные приложения получаются стабильные и неприхотливые к требуемой памяти без каких либо внешних зависимостей.
alexey_public
04.12.2024 12:30Аналогично, я практически всю работу по сложным выборкам отдаю на хранимки, если ещё и поработать с оптимизацией то работает замечательно.
Но десктоп почти умер, а в С++ нет ничего подобного :-( Вот и мучаюсь.
SpiderEkb
04.12.2024 12:30Насколько знаю - нет. В РФ как минимум 4-ре банка живут на платформе IBM i (AS/400). А там свой язык - RPG. Ровесник Кобола, но в настоящее время развился до нормального процедурного языка. И при этом, как и Кобол, является специализированным языком для работы с БД и реализации бизнес-логики.
Скрытый текст
Key Features and Strengths
Known for its user-friendly nature, productive capabilities and seamless integration with the AS400 environment, AS400 with RPG boasts several key features and advantages. These includes:
Native Integration: RPG tightly integrates with the IBM i operating system, enabling developers to seamlessly access system resources and databases.
Business Logic Focus: RPG is specifically designed for articulating business rules and workflows, making it well-suited for transaction processing and enterprise applications.
Data-Centric Approach: RPG demonstrates exceptional proficiency in managing structured data, offering robust data manipulation capabilities within AS400’s DB2 database.
Procedural Programming Model: RPG adheres to a procedural programming paradigm, streamlining program logic and expediting development.
https://thorgroup.com/blog/as400-with-rpg-the-developers-secret-weapon-for-modernization/
Проблема перехода с COBOL/RPG куда-то еще в том, что это специализированные языки. Они содержат в себе много вещей, которые в других языках так просто не реализовать - потребуются внешние библиотеки/фреймворки, код будет сложнее, скорее всего будет просадка в производительности что потребует наращивания мощностей железа (а банковские серверы это не то, что можно в любом магазине купить, там и мощность нужна и, главное, надежность - все это стоит очень ощутимых денег).
Т.е. любой такой переход - очень долго и очень дорого. И, главное, вложения не отобьются, не принесут какой-то дополнительной прибыли. Все будет работать точно также, только потратите денег и времени.
И тут не надо ориентироваться на "нерелевантный опыт" - если вас это волнует, ищите работу где-то в другом месте. Банк живет по своим законам и метрики там тоже свои. Это отдельная, достаточно замкнутая область. Как и, к примеру, промавтоматизация.
claimc
04.12.2024 12:30Сама по себе точность оценки сроков как-то влияет на качество или скорость выполнения задачи? Это же просто формальность, необходимая для создания иллюзии контроля над процессом. Попытка натянуть методы, применяемые в промышленном производстве, на абсолютно иной вид деятельности.
ALexKud
04.12.2024 12:30Mожно подумать что программирование ограничивается одним WEB и джавой. Существует множество средних и мелких компаний, у которых внутренних задач столько что их делать и не переделать так как основной элемент у них - электронные таблицы . Web и джава там нужны как козе баян в задачах производства и сервиса своей продукции, к примеру. Программисты там нужны и на микроконтроллеры и на сопуствующее ПО сервиса и производства приборов к примеру. Зарплаты там неплохие, но меньше чем в компаниях которые занимаю WEB на продажу и не такая потогонная система . Зато можно получить опыт как программиста и не ловить журавля в небе. А уж потос решать, нужно ли тебе рвать жилы в WEB компании или все-таки работать ради жизни а не жить ради работы.
SpiderEkb
04.12.2024 12:30Да, все верно. Уже написал выше - ровно тоже самое относится и к банкам (если говорить о том, что работает на центральных серверах). Там все очень консервативно, просто так, рефакторингом ради рефакторинга никто никогда не занимается. Свой мир - свои правила. Туда не приходят на год-два. Чтобы чего-то достичь нужно там проработать несколько лет пока во все тонкости конкретной системы вникнешь. Но и платят прилично за это. Потому текучка очень низкая.
uzverkms
04.12.2024 12:30Берем самую простую задачу которая есть на проекте и говорим - она занимает один стори-поинт.
Автор концепции стори-поинтов вкладывал иной смысл https://ronjeffries.com/articles/019-01ff/story-points/Index.html
"Here we’ll talk about “Story Points”.
In XP, stories were originally estimated in time: the time it would take to implement the story. We quickly went to what we called “Ideal Days”, which was informally described as how long it would take a pair to do it if the bastards would just leave you alone. We multiplied Ideal Days by a “load factor” to convert to actual implementation time. Load factor tended to be about three: three real days to get an Ideal Day’s work done.
So, as I recall it, we started calling our “ideal days” just “points”. So a story would be estimated at three points, which meant it would take about nine days to complete. And we really only used the points to decide how much work to take into an iteration anyway, so if we said it was about 20 points, no one really objected."
Второй вариант - kanban
Эта практика честно украдена c производства Toyota. Правда там это были физические бумажки на доске, а у нас тикеты в Jira, но сути это не меняет.
"Канбан" Тойоты и "Канбан-метод" - разные штуки. Там это были карточки на ящиках с деталями
FurySeer
04.12.2024 12:30Сейчас от разработчика ждут не только написание кода, но и работу с ci/cd, тестирование, поддержка сервиса в проде, эффективную коммуникацию с командой, а иногда и с бизнесом
Это, как и разговоры о специалистах с любой буквы, вроде T - (как всегда) желание бизнеса сэкономить.
Понимать устройство и принципы работы смежных инструментов - один разговор, бегать от кода к пайплайну через тестирование после созвона с продукт овнером - другой. Если у конторы нет денег на девопсов и тестировщиков - нужно менять контору
Gromilo
04.12.2024 12:30Зависит от размеров проекта. Чем меньше - тем больше ролей и это естественно.
Моя основная специализация - бэкендер. На одних проектах могу только бэк писать, а могу брать роль тимлида, QA, PM, поддержки и аналитика. На самом деле, слов много, а суть одна: маленький проект и ты на нём делаешь всё. При том смежное ты делаешь совсем не в том объёме, как делают когда нужные отдельные люди на роль. Ну типа тимлид в команде из 3-х человек и 30-ти - это совсем разные навыки.
А ещё я не могу работать "жиродробителем". Если мы моя работа была бы только "вот карточки, там всё понятно что делать, делай их до пенсии", я бы долго не выдержал.
esisl
04.12.2024 12:30"Да правильно все говорит" (с)
Хоть как-то оценить время на выполнение можно только для рутинных задач. Для всех остальных "сначала надо изучить вопрос, зайдите завтра... или через неделю"
И насчет "невозможно знать всё" тоже правда. Хуже того. Например, "плывет" терминология. Причем и во времени и в пространстве :)
freylis
04.12.2024 12:30Подберите такую задачу, что N стори-поинтов на ее выполнение занимали ровно 1 час и возьмите за основу не 1 стори-поинтов, а N
Замените N стори-поинтов на 1 час
Прекратите выпендриваться
Frankenstine
04.12.2024 12:30Без какого языка нельзя представить современный мир?
Внезапный ответ: самый важный язык — это COBOL, созданный в 1959 году.
Да это же байка из США. В других странах всё гораздо моложе в банковской сфере и кобола там скорей всего практически нет.
ПыСы чатгопота со мной согласен
Это скорее миф, что COBOL "повсеместно" используется. Сегодня его применение ограничено определёнными доменами (например, банкинг и госструктуры), где существуют устаревшие, но критически важные системы. При этом новых разработок на COBOL практически нет. Вместо этого современные языки, такие как Java, Python и другие, используются для создания новых систем, а COBOL-системы постепенно интегрируются или заменяются
cross_join
04.12.2024 12:30Позитивный подход: "Я - дилетант, мои коллеги - дилетанты, поэтому команде надо больше общаться, чтобы
, как анонимным алкоголикам, не впасть в депрессиюне выгореть за пару месяцев"Gromilo
04.12.2024 12:30А что делать? Все когда-то такими были.
cross_join
04.12.2024 12:30Мы получали знания от преподавателей, наставников, из книг и практической работы, а не ежедневной болтовнёй с такими же дилетантами
muxa_ru
04.12.2024 12:30ведь все это время использовал совсем другие инструменты: вместо Kafka — RabbitMQ, вместо Postgres — MongoDB, а вместо Kubernetes — OpenShift.
А кто-нибудь пробовал не переизобретать каждый раз один и тот же велосипед, а просто освоить уже имеющийся и эффективно им пользоваться?
sved
04.12.2024 12:30Есть ещё один способ правильно оценить сроки - работает на ура. Дать сутки на то чтобы вникнуть в суть проблемы, разобраться с требованием и прикинуть, как решать задачу. Понятно, что если кто-то пытается за 15 минуть оценить задачу хоть в поинтах, хоть в попугаях, то это всё равно что ткнуть пальцем в небо.
Что касается T-shape, то есть вещи которые обязан знать любой разработчик. Для Java это будет Java, maven/gradle, Spring. Также все бэкэнд разработчики должны хорошо разбираться в сетях, linux, реляционных БД.
Те кто имеет пробелы в базовых вещах - пусть доучиваются
yar229
04.12.2024 12:30Многие системы на COBOL работают десятилетиями.
Те, кто создавал систему, давно ушли из компании (или из программирования).
(или из жизни)
SpiderEkb
04.12.2024 12:30НА мой взгляд там нет каких-то критических проблем. Да, разработчиков на COBOL мало. Но их много и не нужно. Это узкоспециализированный, нишевый язык. Сообщество по нему есть, курсы по нему есть. Платят за него вполне нормально. Так что там есть достаточное количество разработчиков.
Ну и в РФ он практически не используется. Так что и разработчики на нем тут не требуются.
Аналогично - IBM i/RPG - в РФ минимум 4 банка на этой платформе. Плюс есть вендоры - BTC, Cinimex, RMS-Lab (может еще кто-то). Тоже в это все умеют. Да, ниша. Да, мало. Но какой-то критической нехватки кадров нет. Немного, но хватает для решения задач.
Android1983
04.12.2024 12:30Привет автору.
Есть несколько мыслей по поводу статьи.
Мысль 1: Хоть я и не являюсь действующим программистом, а только заканчиваю учится на программиста всё же я пришёл к тому же мнению что описано у тебя в статье.
Мысль 2: Для написания Дипломной Работы дано 2 + 1 месяца работы, то есть 2 месяца на разработку и месяц на доработку. Так как я начинаю только писать вообще что-то то я решил не париться по причине того как я буду писать свой проект, для меня главное чтобы большее из того что я задумал просто работало.
Ну и на последок не совсем мысль а больше вопрос. Как научиться учиться в IT. Суть в том что тупо спрашивать на форумах это непонятно так как ответы есть но и пробелы в коде-знаниях тоже ни куда не деваются. Отсюда вопрос откуда черпать информацию если нужно за условные 5 дней узнать что-то и это же самое реализовать. Например в моем случае это Rest API на PHP с доступом к нему из браузера по возможности не используя react, laravel и Node.js
monpa
Кошмар... Одни Пятнадцатерублевые боты в комментариях.... Куда катится Хабр...
anticyclope
– Господин Рейган, примите наши соболезнования в связи с катастрофой шаттла "Челленджер"
– Но "Челленджер" взлетает только через час, мистер Горбачёв!
– Простите, я перезвоню через час.
nbkgroup
Русские выразили соболезнования за два часа до аварии, мистер президент.
victor-homyakov
– Так, что там у них на букву "Ч"?
– Чернобыль
qeeveex
Странно шутить про катастрофу унесшей 7 человек.
unC0Rr
Такие вот советские анекдоты.
myswordishatred
Нормально. В том смысле, что над жертвами-то никто не смеётся.
А то давайте анекдоты про Чапаева и Штирлица запретим: в гражданскую куча людей погибла, а в отечественную вообще какие-то цифры космические.
xaosxaos2
Уже, на днях на твиче в тему попытался анекдот из далекого прошлого рассказать, получил не одобряю и удаление сообщения.
vvzvlad
А еще про что нельзя шутить?
Tamashii
Просто нельзя.
Wesha
Ну раз про сто нельзя, то хоть про девяносто девять-то можно?
aldekotan
В самые тёмные времена, чёрный юмор - то немногое, что действительно помогает. Хотя бы морально
Megakazbek
Вселенная станет гораздо лучше, если все перестанут на это обижаться.
dyadyaSerezha
А почему пятнадцатирублевые? Мне всегда больше нравились 18-рублевые купюры, на них картинка красившее.