Комментарии 323
Кошмар... Одни Пятнадцатерублевые боты в комментариях.... Куда катится Хабр...
– Господин Рейган, примите наши соболезнования в связи с катастрофой шаттла "Челленджер"
– Но "Челленджер" взлетает только через час, мистер Горбачёв!
– Простите, я перезвоню через час.
Русские выразили соболезнования за два часа до аварии, мистер президент.
Странно шутить про катастрофу унесшей 7 человек.
Такие вот советские анекдоты.
Нормально. В том смысле, что над жертвами-то никто не смеётся.
А то давайте анекдоты про Чапаева и Штирлица запретим: в гражданскую куча людей погибла, а в отечественную вообще какие-то цифры космические.
А еще про что нельзя шутить?
Просто нельзя.
Вам номера статей ук назвать?
Да, пожалуйста.
280.1, 284.2, 280.3, 205.2, 148, 319
И каким боком тут шутки? Статьи за призывы.
Впрочем, я уже заметил, что суды — они уже достаточно давно способность воспринимать печатную речь потеряли.
Вот вы тут сус^H^H^Hпризыв видите?
должно быть побудительным, а тут — повествовательное.
Ну пошути про "норд-ост" или про коран, например, и узнаешь "каким боком".
Да нема базара. «Почему террористы в „Норд‑Осте“ ничего не добились? Потому что были под газом.» Ваш ход.
9 декабря 2024 гражданин Wesha разметил в социальной сети habr сообщение о том, что территористы, в ходе совершения терракта в "Норд-Осте", могли добиться выполнения своих политических требований, если бы не подверглись воздействию психотропных веществ, что, согласно приложенному лингвистическому заключению, содержит высказывание, являющиеся публичным оправданием террористических действий и формирует состав преступление в рамках статьи УК РФ 205 часть 2...
Ну так я и говорю, что любой нормальный адвокат написанный Вами бред на кирпичики разнесёт, потому что сейчас это уровня «я его не поняла и поэтому обиделась».
Давайте попробуем зайти с другой стороны: у того же Навального был нормальный адвокат?
Навальному я могу ответить исключительно словами Папанова.
Рекомендую телегу нормального, высокопрофессионального адвоката "Новости клики Тито". Бложик не профессиональный, но порой содержит некоторые интересные детали. Узнал много нового из этого мира.
У вас невероятно наивное представление о том, как работает "судебно-следственная" система в РФ и какую функцию в ней выполняет адвокат. А касательно реальной практики по статьям за "шутки" - почитайте про уголовное дело Василия Большакова, например. Вы можете не верить "людям в интернете" - поговорите с любым адвокатом по уголовным делам, спросите какая сейчас практика по указным статьям, какие шансы закрытия уголовного дела если оно уже возбуждено и т.д.
В самые тёмные времена, чёрный юмор - то немногое, что действительно помогает. Хотя бы морально
Вселенная станет гораздо лучше, если все перестанут на это обижаться.
А почему пятнадцатирублевые? Мне всегда больше нравились 18-рублевые купюры, на них картинка красившее.
Оценивать в часах бессмысленно
Чушь полная. Все ваши сторипоинты потом всё равно сконвертируются в часы, потому что каждый сотрудник работает 40 часов в неделю, и никак иначе. Понятно, что каждый сотрудник может выполнить разный объём работы за эти 40 часов, но поэтому у сотрудников бывает разная почасовая ставка. Игнорировать тот факт, что бухгалтерия в расчётах оперирует часами, это то же самое, что заметание мусора под ковёр. ПМ снимает с себя головную боль в виде подсчёта капасити команды, а в конце года бухгалтер поднимает ковёр, а что у нас под ковром? Правильно - под ковром у нас кассовый разрыв.
Ждем какое-то время, и замеряем сколько занимает переход задач из статуса To Do в статус Done
Ээээээ, серьёзно? Это же получится средняя температура по больнице. Одна задача - перекрасить кнопку, вторая задача сверстать целую форму. В итоге форму верстали два дня, а кнопку красили три недели, потому что QA был в отпуске.
Ээээээ, серьёзно? Это же получится средняя температура по больнице. Одна задача - перекрасить кнопку, вторая задача сверстать целую форму. В итоге форму верстали два дня, а кнопку красили три недели, потому что QA был в отпуске.
Именно из-за того что форму верстают два дня а кнопку красят три недели - единственный хоть как-то работающий способ "средняя температура по больнице"
Единственный работающий способ - это когда ПМ спрашивает разработчика, сколько ему потребуется на такую задачу, потом докинуть время на QA и поправку на непредвиденные обстоятельства. Затем разраб должен внести время, реально затраченное на задачу (автоматическим тайм-трекером или вручную - неважно), QA должен внести своё время. В конце спринта, даже если QA был в отпуске, ПМ должен посмотреть, сколько затраченного времени внесено в задачу и сравнить это с первоначально выставленной оценкой. Если затраченное время сильно расходится, ПМ должен всё зафиксировать где-то у себя, и учитывать при последующих планированиях. На самом деле, это немного похоже на то, что вы сказали, но замерять надо не время от ToDo до Done, а соотношение реально затраченного времени к оценке.
Согласен, тут логичнее не от ToDo, а от InProgress
Я описал два подхода:
1. Мы сравниваем реально затраченной время с оценкой в сторипоинтах, и постепенно начинаем понимать сколько в данной конкретной команде часов занимает один сторипоинт.
2. Мы просто замеряем затраченной время на задачи, без первоначальной оценки, собираем статистику по перцентилям, и на основе этого делаем прогнозы по следующим задачам.
По крайней мере, я на практике встречался с этими двумя подходами, и они работали достаточно точно.
Но наверняка есть и другие варианты, тут мне спорить не с чем
В итоге всё всегда сводится к тому, чтобы по результатам ретроспективы корректировать оценку производительности сотрудников.
постепенно начинаем понимать сколько в данной конкретной команде часов занимает один сторипоинт
Зачем нужна оценка в сторипойнтах, если в реальности все равно существует явный или неявный перевод из сторипойнтов в часы? И в итоге все равно все сводится к часам.
Скорость выполнения в часах зависит от человека/команды, а сторипоинт дает гранулярность того насколько задача простая для всей фирмы условно говоря.
"Фигня, но не прям фигня, посложнее чем прям фигня, но все еще фигня, легче чем охренеть" и всякое такое, превращается в три сторипоинта, и это позволяет, зная среднюю скорость в сторипоинтах в месяц, абстрактно задач напихать в бэклог "типа чтобы до конца года хватило плюс-минус", а потом когда до каждой дело доходит, уже идет "ну A такое сделает за два часа, но у него завал, а B закопается на целый день, но ему делать нечего, поэтому ему поручим, и срок будет два дня"
Скорость выполнения в часах зависит от человека/команды
когда до каждой дело доходит, уже идет "ну A такое сделает за два часа, но у него завал, а B закопается на целый день
И в чем разница? Правильно, ни в чем.
зная среднюю скорость в сторипоинтах в месяц, абстрактно задач напихать в бэклог "типа чтобы до конца года хватило плюс-минус"
Перефразирую - зная среднюю скорость в часах в месяц, абстрактно задач напихать в бэклог "типа чтобы до конца года хватило плюс-минус".
В реальности тут есть нюанс, чтобы напихать задач в бэклог до конца года надо их все оценить (неважно в чем), лучше спринтами, но это тонкости.
насколько задача простая для всей фирмы
Тоже какая-то средняя температура по больнице. Для одного человека, который допустим эксперт по какому-то фреймворку, задача вообще ерунда на полчаса неспешной работы, для другого эта же задача на день - пока разберешься, пока поймешь что делать, пока ошибки отладишь..
А одного эксперта на все задачи может и не хватить, он не резиновый, вот и получится что один черт измеряется этими сторипоинтами что-то непонятное и с потолка.
Они и есть средняя средняя температура, в этом и прелесть, для этого они и нужны. Размазано по долгому сроку, они дают достаточную плюс-минус оценку, без того чтобы на этапе предварительного планирования вдаваться в мелочи типа кто что за сколько времени делает. При достаточно грамотном использовании, они дают достаточно достоверный метод быстро прикинуть сколько всего можно сделать за сколько времени, в среднем, абстрактно, без подробностей. Вместо того чтобы закапываться сразу в гранулярное планирование, которое все равно в итоге покажет погоду на марсе.
Что-бы это работало - статистику надо аккуратно и грамотно собирать, и учитывать еще массу всего, ведь бездумно эти циферки тоже не получится использовать. Это какая-то запредельно крутая культура разработки, как по мне, лично я такого в реальной жизни не встречал. Чаще все это похоже на какой-то бессмысленный ритуал в секте. Хотя, конечно, у ритуалов есть смысл, но он не про работу и эффективность, он про психологию - это метод привести людей в подчинение, что-бы они бездумно и быстро выполняли любые, даже самые абсурдные приказы.
Например чтобы потом не было претензий а ля "Тебе дали на день задач на восемь часов, а ты сделал только на 6. Чем ты занимался два часа?".
Разве оценка в сторипойнтах уберет такие мудацкие претензии? Просто станет вот так "Тебе дали на день задач на восемь часов на два сторипойнта, а ты сделал только на 6 на один сторипойнт. Чем ты занимался два часа оставшееся время?"
Мудацкие претензии и способ оценки задачи вещи несвязанные. Можно и до сторипойнтов докапаться, можно и по часам оценку нормально использовать.
Но при этом я могу задать один простой вопрос: А где написано что за день надо делать ровно два сторипоинта?
"Все остальные делают в среднем 2 сторипоинта, значит и ты должен"
Напомним, что вводная - "у менеджера есть цель докопаться", от неё замена часов сторипоинтами не спасает.
Ещё как поможет. Потому что разработчику тоже никто не мешает "включить дурака" и начать докапываться уже до менеджмента на каком основании ему выдвигают претензии.
И если задача оценена в часах, то отбиться будет гораздо сложнее.
на каком основании ему выдвигают претензии
Докопаться можно и до столба, почему он стоит. А тут докопаться проще простого - все перформят 2 СП в день, ты раньше перформил 2 СП в день, а теперь один, халявишь поди.
На всякий случай уточню свою позицию - я не говорю что это хорошо, что это правильно, что это повсеместно. От мудаков замена часов на сторипойнты не спасет, найдут к чему прицепиться.
все перформят 2 СП в день
Их проблемы. Где у меня в трудовом договоре написано сколько СП в день я должен перформить?
От мудаков замена часов на сторипойнты не спасет, найдут к чему прицепиться.
Это может быть не спасает в любой ситуации. Но это увеличивает шансы.
П.С. А вообще если такое начнётся, то мне с фирмой не по пути. И вопрос скорее идёт о том с какой компенсацией меня уволят.
Ответ зависит от степени мудаковатости.
Легкая степень - ну как откуда, по результатам последних десяти спринтов средняя производительность в день 2,17 СП. При планировании спринта на тебе 20 СП. Не, если оценка неверная, ты скажи, мы на ретро все подробно обговорим. А пока завтра на дейлике подробно расскажи какие у тебя были проблемы, обсудим.
Тяжелая степень - а сколько тебе надо, неделю что ли? Скоуп работ на тебе есть, там два СП в день. Или может хочешь вообще без сроков и планирования работать, типа когда сделаю, тогда сделаю? Так не пойдет. Если задача большая, разбивай на подзадачи не больше одного дня. В общем, когда будет готово? Назови точный срок.
Отвечать они могут что угодно. При этом если уж такое начнётся, то только письменно.
А потом уже в зависимости от "степени мудаковатости" будет привлечён мой начальник или начальник моего начальника или даже адвокат.
Но в любом случае сторипоинты дают разработчику больше "амуниции" для таких разборок. Потому что получается что лично он под конкретным сроком нигде не расписывался.
Чем ты занимался два часа?
Отвечал на ваши письма, конечно же!
Был у нас разговор с аналитиками буквально на той неделе... я им про часы, а они мне - один про футболки, второй про сторипоинты. Мол, в часах оценить невозможно. Зато вот футболка XXL и 10 поинтов - это большааая задача. И можно прикинуть что она стоит примерно... 40 часов.
Я им - так получается всё равно к часам возвращаемся? Ну да... но нет... но да...
Короче, это всё равно что спорить в чём мерить длинну - в футах или в метрах. Где как принято, там так и мерят. Хуже всего получается когда у одних фут британский (~0.3м), у других бразильский (~0.33м), а у последних римский (0.25м). Потому-что ноги у всех разные, как и размеры футболок или, прости господи, стори поинтов.
К чему я? Да к тому что есть универсальная, а главное, точная единица - часы. Точнее неё вам ни поинты, ни футы, ни футболки, ни любая другая абстрактная единица не оценит задачу.
Да, всё-равно возвращаемся к часам. Но, нет, это другое. :-)
Фишка в том, что оценка в сторипоинтах универсальна для всех разработчиков, потому что описывает относительную сложность задачи - относительно другой, минимальной, задачи. А вот оценка в часах для разных разработчиков для одной и той же задачи может очень сильно отличаться - в зависимости от кучи факторов, начиная от джун/сениор и заканчивая тем знаком ли конкретный разработчик с данным типом задач и насколько конкретно этот разработчик любит затягивать задачи делая разные посторонние штуки (напр. пытаясь сделать более гибкое/универсальное/красивое решение чем реально необходимо).
Поэтому переводить в часы имеет смысл когда уже понятно кто именно из команды будет делать эту конкретную задачу. И если задача передаётся от одного разработчика другому то оценку в часах нужно корректировать. И это ещё простой случай, потому что если обсуждаемая задача не является низкоуровневой микротаской для разработчиков а является более высокоуровневой бизнес-задачей, над которой по определению должны работать несколько разных людей (дизайнер, разработчик, тестировщик), то такую в часы конкретного разработчика в принципе переводить бессмысленно, и можно только статистически через какое-то время выяснить среднее отношение между сторипоинтами и человеко-часами (а, скорее, человеко-неделями).
Поэтому и получается так, что "перевести в часы" - можно, а сразу назвать "в часах" - нет.
В вашей логике есть изъян, вот в этом месте:
Фишка в том, что оценка в сторипоинтах универсальна для всех разработчиков, потому что описывает относительную сложность задачи - относительно другой, минимальной, задачи
Сторипойнты тоже не универсальны. Все что вы описываете про часы - уместно и для сторипоинтов. Или все разработчики способны оценивать сложность задач одинаково? Пусть даже относительно простой задачи?
Для выравнивания оценок в сторипойнтах придумали целый ритуал с покер планированием.
Вот и возникает вопрос, а нафига они нужны? Почему сразу не использовать часы, если нет разницы? Звучит более модно? Цифры Фибоначчи проще воспринимать чем реальные часы? Или это такой способ сбросить ответственность?
Иногда доходит до абсурда, когда и часы и сторипойнты используют. И потом переводят сторипойнты в часы, чтобы дать стецкхолдерам прогноз по срокам. Или чтобы по методу освоенного объема контролить показатели проекта.
Кстати, большие куски работы даже проще оценивать. Особенно если есть похожий опыт. Например, интеграция платежной системы, ага, 3 недели, 120часов. И выставляешь по перту 100ч в идеале, 160ч пессимистично, и считаешь по формуле смещенное среднее.
Или все разработчики способны оценивать сложность задач одинаково?
А вот тут и появляется польза от Фибоначчи. Да, мнения разных разработчиков про задачу "раза в 2 сложнее самой простой" скорее всего совпадут, а вот в отношении задачи "раз в 5 сложнее самой простой" скорее всего разойдутся: кто-то скажет в 4 раза, кто-то в 5, кто-то в 6 - и тут очень удобно, что среди возможных ответов есть только 5. Между вариантами "в 2 раза" и "в 8 раз" мнения обычно не расходятся, а если такое и происходит, то это повод подробнее обсудить в чём причина расхождения, после чего обычно мнения синхронизируются на одной из оценок.
Фишка в том, что оценка в сторипоинтах универсальна для всех разработчиков, потому что описывает относительную сложность задачи - относительно другой, минимальной, задачи. А вот оценка в часах для разных разработчиков для одной и той же задачи может очень сильно отличаться
Не будет она универсальная, что для одного сложно, для другого просто, кто-то опытный, кто-то нет. Кто-то похожую задачу делает уже в нный раз и все знает, а кто-то в первый и ему разбираться там что да как.
Поэтому переводить в часы имеет смысл когда уже понятно кто именно из команды будет делать эту конкретную задачу.
А зачем вообще это делать? Контролировать время по каждой конкретной задаче это хрень. Есть производительность в сторипойнтах у команды в целом, кто-то больше выдает, кто-то меньше. Если мерить в сторипойнтах, конечно.
такую в часы конкретного разработчика в принципе переводить бессмысленно
Оценка имеет смысл для команды в целом и в среднем за спринт. Так все усредняется и можно дать более-менее реалистичный прогноз. А в одной конкретной задаче неопределенность слишком большая. Неважно как оценивать.
можно только статистически через какое-то время выяснить среднее отношение между сторипоинтами и человеко-часами
Как ни крути все в конечном итоге превращается в часы.
Это в случае одной задачи.
А когда разработчик делает несколько задач - все становится сложно и малопредсказуемо по срокам.
Почему это? Большие задачи потому и делят на много маленьких, потому что оценка маленьких задач всегда будет точнее.
по срокам
Прогнозировать надо не срок выполнения задачи, а время, которое будет затрачено на её выполнение. Нельзя говорить "я сделаю эту задачу к четвергу", нужно говорить "я сделаю эту задачу за 10 часов". Есть другие срочные проекты - всегда пожалуйста. Пусть задача будет готова даже через год, но если за этот год на неё будет потрачено всего лишь 10 часов, значит оценка была дана верно.
>Большие задачи потому и делят на много маленьких, потому что оценка маленьких задач всегда будет точнее
Не поэтому, на самом деле, это лишь распространенное заблуждение. На самом деле все точно наоборот - чем меньше задача, тем менее точной будет оценка, в силу того что риски не усредняются.
Оценка такой мелкой таски будет тем точнее, чем меньше таска. Так что это не совсем заблуждение. Риски не усредняются, да, но и сами риски по мелким таскам тоже мелкие, и даже срыв сроков по мелкой таске в разы почти никак не скажется на общем прогрессе проекта, ведь такое будет происходить с небольшим процентом задач.
Тут есть немного другой аспект: после декомпозиции может быть сложнее оценивать время, которое требуется на то, чтобы из кучи мелких задач собрать крупную бизнес-фичу. Потому что да, там появляются дополнительные риски, которые в мелкие задачи не заложены - начиная от того, что в процессе работы требования могут изменяться и это может приводить к тому что количество мелких задач вырастет раза в 2-3, и заканчивая тем, что в этих мелких задачах редко закладывают риски связанные с интеграцией/прохождением ревью безопасников/ожиданием дизайнера или тестировщика и т.п. Тем не менее, это всё решаемые проблемы - как отдельной оценкой крупной бизнес-таски традиционными способами так и налаживанием процессов которые будут минимизировать упомянутые риски.
Оценка такой мелкой таски будет тем точнее, чем меньше таска.
Я и говорю - это просто глупость, которую один дурак когда-то сказал, а остальные дураки - повторяют.
но и сами риски по мелким таскам тоже мелкие
На самом деле риски по мелким задачам существенно крупнее, чем по большим. Это достаточно очевидно. Но даже если их не считать больше, а считать такими же - то в итоге для большой задачи оценка будет точнее все равно.
Если у вас есть несколько одинаковых независимых случайных величин с положительным матожиданием, и вы их будете суммировать - то матожидание растет линейно от n (количества задач), а стандартное отклонение - пропорционально корню, с-но точность оценки растет пропорционально корню от размера задачи (на самом деле даже не самой оценки - а в принципе неопределенность в сроках уменьшается, с-но уменьшается и неопределенность в оценке).
Это как бы очевидно и на конкретных примерах - допустим, у вас есть задача на два часа. Если вдруг случится какой-то несущественный риск - то вместо 2 часов будет 4 часа, это 100% отклонения. И такие отклонения для задач подобного размера - обычное дело, они постоянно происходят и на них особ внимания ни кто не обращает. С другой стороны, если у вас задача на год, то 100% отклонение крайне маловероятно (и считается уже не нормой, фактически это проваленный проект в 9 случаях из 10).
Точность оценки в случае маленьких задач возникает просто из-за того, что они лучше и подробнее поставлены - любая неопределенность в постановке всегда закладывается в риски, т.е. в + к оценке, что снижает точность. Маленькие задачи же ставятся конкретно, что снижает неопределенность. Если же большая задача и маленькая поставлены одинаково - то для большой задачи ниже риски, с-но точнее оценка.
Судя по всему, Вы - математик: даёте точный, но совершенно бесполезный ответ.
На практике у нас и величины не случайные, и точность оценки маленьких задач возникает не только потому что они лучше и подробнее поставлены (нередко всё совсем наоборот, из-за того что задача маленькая она вообще детально не описывается помимо того что в названии задачи), и в случае "задачи на год" типичное отклонение будет не 100% (которое Вам кажется маловероятным) а все 200% (потому что сроки в среднем срываются в 3 раза), и нет, срыв сроков по маленьким задачам - это исключение, а не "обычное дело".
То, что Вы описали - это теория. Причём базирующаяся на неверных входных данных, что ещё больше всё портит. А я описываю как оно работает на практике. И на практике единственный работающий способ получить достаточно точную оценку сколько времени займёт реализация функционала размером примерно на 3-4 человеко-месяца - это декомпозировать его на задачи размером от 1 часа до 3 дней, сложить сроки задач и умножить на корректирующий коэффициент для конкретной команды, причём чем меньше будут задачи тем точнее получится финальная оценка.
Я даже допускаю, что если понять фразу "чем меньше таска" буквально (как математик) и попытаться дробить на задачи не в интервале 1 час - 3 дня (со средним размером задачи примерно 0.5-1 дня) а на задачи в интервале 1-60 минут (со средним размером задачи в 23 минуты), то мы действительно получим описанный Вами результат в виде сильного уменьшения точности оценок. Но на практике так всё-равно никто не делает, потому что глупость такого подхода очевидна всем.
Ваша теория работает, если вы хотите точный календарный срок для каждой задачи. Да, с этим у маленьких проблемы. Большее число задач будет сделано не в планируемый час.
А вот если вы хотите повысить точность оценки спринта, то в команде из 7 человек если вы будете бить один и тот же объем работ на 7 частей или на 35 дисперсия для 35 будет ниже как раз за счет количества.
Это даже если не вспоминать, что задачку на полдня подхватит первый освободившийся, а когда у каждого по одной задаче на спринт, то половина задач будет просрочена просто потому, что человек до последнего будет говорить "отстаньте, я в графике", пока успевшие раньше будут делать полезные, но не целевые (в этой итерации) задачи.
оценка маленьких задач всегда будет точнее
...вот только непонятно будет — придётся ли эту маленькую задачу делать, или мы решили пойти другим путём.
Да и то не особо оно работает. Точнее работает, но на очень ограниченном подмножестве задач. Всякие простые доработки в простом и вдоль и поперек изученном фреймворке - да, тут более-менее. А уже исправление багов - нифига не работает. Вот поступил баг - какие-то данные обсчитываются не так как должны (не все подряд и не всегда, только в некоторых случаях). У разраба спрашивают - сколько времени надо на исправление? В подавляющем большинстве случаев он просто не знает этого. Не знает потому что само исправление обычно занимает считанные минуты, а вот поиск места, куда это исправление надо внести, может потребовать часы, а то и дни или недели. Бывают такие гадкие баги, что исправляются они чуть ли не месяцами и разными разрабами.
Та-же ерунда и с новым функционалом, который делается не по старой, накатанной схеме. В процессе могут всплыть столько неучтенных нюансов, что ни о какой определенности и говорить нечего.
Это тоже решается. Просишь N часов на инвестигейт. Далее ПМ объясняет клиенту, что вот у нас тут неведомая фигня, надо столько-то часов только чтобы понять, что это.
И как понять - сколько просить? Вот я уже очень много лет работаю и до сих пор не знаю "сколько в часах". Ну да, я на практике прошу обычно какое-то время, но это всегда оценка по большему счету с потолка взятая. Бывает что очень быстро разберешься, а бывает что днями логи и код изучаешь, и ходишь кругами около какой-то особо заковыристой проблемы, а потом оказывается что там какая-либо ерунда была, исправляемая парой строчек кода..
Сначала просить немного, чтобы хватило просто вникнуть в контекст и оценить насколько данный баг простой/сложный/неведомая хрень. Если баг окажется простым, то он за это время будет заодно и исправлен. Если сложным, то за это время получится выработать вторую, более точную оценку сколько времени потребуется на его выявление и обнаружение. Если за это время даже идей никаких не появилось т.е. понимания больше не стало, то это значит что в этот баг можно закопаться на неопределённое время, и тогда нужно просто двигаться "интервалами" - выделять фиксированное время (день/два) после которого принимать решение стоит ли вообще продолжать исследовать этот баг данному разработчику (выделяя следующий день/два), или лучше передать его более квалифицированному разработчику либо вообще забить и не исправлять его (ну или заткнуть каким-то хаком).
Спрашивает разработчика?))
1. Если пм спрашивает разработчика это не пм вовсе а передаст и ставку его лучше отдать разрабам или понизить до секретаря и все равно отдать разрабам
2. а разработчик откуда знает? Я понимаю что вы привыкли выжимать из разрабов эти оценки но они абсолютно с неба взяты. Я вот +- могу на длинной дистанции как то оценивать и для этого мне всего то потребовалось 20 лет опыта, фигня какая...
3. потрекать время? самое беспощадное и бесполезное занятие которое вообще бывает. По целому ряду причин, начиная с мнения что якобы платят за время а не за 20 лет опыта, и заканчивая тем что в таком случае можно вносить 24 часа в табели, поскольку некоторые разработчики думают над задачами на прогулках и перекурах.
якобы платят за время а не за 20 лет опыта
Хотите сказать, что вы можете себе позволить вообще не работать ни одного часа (ой, простите, сторипоинта) в месяц и вам заплатят полную зарплату? Так вы же можете тогда устроиться одновременно во все компании в мире и получать зарплаты в них всех!
Мне думается, платят все-же за сделанную работу, и сделанную в какой-то разумный срок. Любой разумный человек понимает что соблюсти сроки с точностью до часа на большом и сложном проекте - это нереально в принципе, слишком много неопределенности, но все-же какие-то сроки и оценки нужны, это понятно.
И опыт как раз и позволяет сказать - вот эту подсистему, скорее всего команда будет пилить пару месяцев, задача более менее ясна, инструменты тоже, и в целом вся ясно.
А вся эта шняга с часами и трекерами, как по мне классический микроменеджмент, бесполезно сжирающий ресурсы разработчика и заказчика тоже, потому что он так-же не бесплатно достается. Разраб вместо того что-бы работать над основной задачей тратит время на то что-бы оценить очередную микроподзадачу, понять сколько он с ней провозится, накинуть время для подстраховки, заполнить всякие там таблички, обосновать оценку, и т.д. и т.п.
Если же работа оценивается более крупными периодами, то все эти подзадачки просто делаются по факту, сделал за полчаса, перешел к следующей, и не морочишь себе и людям голову с трекерами, оценками, записями всякими и т.п. и не тратишь ресурс на все вот это. Так и работать интереснее, не отвлекаешься на всю эту муть, а занимаешься делом.
вот эту подсистему, скорее всего команда будет пилить пару месяцев
Хорошо, когда такая точность оценки приемлема. Но что такое пару месяцев? 2-3 месяца. Ну может четыре. Разбежка месяц минимум. А если в команде 5 человек с зарплатой по 2000$ каждый, то имеем разбежку в 10 тысяч долларов. А может и 20. И это на одной фиче с довольно маленькой командой. Хорошо, когда есть какой-то богатенький буратино, готовый за всё это платить.
Да в реале оно так обычно и бывает. Ну назовут вам срок - 1056,4 часа, вы думаете что именно за этот срок все и будет сделано? Нет, что-то конечно, будет сделано, возможно оно даже будет как-то условно работоспособно и будет проходить какие-то тесты, но это в лучшем случае. Обычно когда есть задача "хоть умри но сделай в срок", то все делается с кучей "срезанных углов", в духе - поправим и доработаем позже (дорабатывать и править, конечно, никто ничего не собирается)
А чаще просто начинают с заказчиком договариваться о том что-бы сдвинуть сроки, что надо что-то доработать, что-то урезать, что-то убрать..
Не надо занижать сроки и недооценивать сложность, тогда и углы срезать не придётся.
Планирование трудозатрат - это целая дисциплина, которую изучают и преподают в вузах не первую сотню лет. Люди как-то слетали на Луну, построили тоннель под Ла-Маншем, приручили атомную энергию. А потом появились айтишники и сказали "оценивать задачи в часах невозможно, мы придумали сторипоинты и отменили дедлайны". И по факту единственный аргумент против оценки задачи в часах - это "мы пробовали, у нас не получилось".
Люди как-то слетали на Луну, построили тоннель под Ла-Маншем, приручили атомную энергию.
У меня как-то сложилось впечатление, что все эти крупно-строительные задачи из кучи железа и бетона - обычно ну ни разу в сроки и бюджеты не укладывались. Так что позиция IT индустрии, возможно, 'честнее'.
С другой стороны - все это бетонно-железное по много десятков лет эксплуатируется, а не как у нас, когда и пяти лет не прошло - все начинают думать 'а не дешевле ли будет все заново сделать, чем с легаси возиться'. Что выглядит немного диковато и, скорее всего, означает, что индустрия просто не умеет нормально учить, как с этим самым легаси работать.
индустрия просто не умеет нормально учить, как с этим самым легаси работать.
Индустрия просто не умеет учить. Абсолютное большинство специалистов либо самоучки, либо выпускники всяких курсов. В машиностроении или архитектуре, к примеру, уровень образования специалистов значительно выше.
А проблема легаси состоит в том, что критически не хватает специалистов с опытом долгосрочной поддержки проектов. Всегда проще сказать "ваш проект легаси, надо всё переписывать", чем разбираться в чужом коде и что-то улучшать. А потом оказывается, что в новом проекте не хватает фич, и клиенту приходится пользоваться параллельно и старой, и новой системой. Тогда решают заново всё переписать, но в итоге уже работают в трёх системах)))
Думать может и думают, но возятся с легаси. У нас в стране IT так-то довольно молодое, на "западе" условном, бывают проекты, которые тянут с времен IT палеолита.
Но в любом случае - даже у "железобетонного" есть предельный срок эксплуатации, после которого его дешевле снести чем его ремонтировать.
Не надо занижать сроки и недооценивать сложность, тогда и углы срезать не придётся.
А еще не надо болеть и надо быть богатым, не надо быть бедным :))
Люди как-то слетали на Луну, построили тоннель под Ла-Маншем, приручили атомную энергию.
Ну, люди "как-то" и винду с Линуксом написали, и браузер в котором мы читаем эти комментарии..
не надо болеть
Вы не поверите, но во-первых, болеть действительно не надо. А вот-вторых, на крупных предприятиях при оценке требуемой списочной численности работников берут в расчёт тот факт, что из условной тысячи работников X человек будет болеть в течение Y дней.
винду с Линуксом
Касаемо майкрософт, я не располагаю данными, как именно они ведут учёт. Касаемо Линукса, львиная доля его кода была написана программистами добровольно и бесплатно вне своего рабочего времени. А ещё часть его кода была написана сотрудниками компаний, заинтересованных в его использовании. И тут вы удивитесь, но во многих компаниях принято выделять штатное время своих сотрудников на контрибьютинг в опенсорс, и там уже у каждого своя внутренняя кухня - кто-то контрибьютит часы, кто-то сторипоинты, а у кого-то вообще может быть тарификация в строках кода.
Вы не поверите, но во-первых, болеть действительно не надо.
Почему-же не поверю? Конечно не надо. Просто это пожелание из разряда недостижимых, как правило люди заболевают не по своей воле и желанию, так-же и с ошибками в оценках задач. Круто уметь оценивать любую задачу с точностью до минут, но это в принципе невозможно для всего множества задач, с которыми приходится сталкиваться в работе.
Круто уметь оценивать любую задачу с точностью до минут, но это в принципе невозможно
А никому и не нужна оценка с точностью до минут. Я не понимаю, почему все постоянно твердят про какие-то минуты. Точное планирование состоит не в точном предсказывании сроков, а в правильном учёте всех возможных вероятностей и закладывании необходимых допусков там, где это нужно. Например, если брать какие-то типовые задачи, то можно смотреть в ретроспективе, например месяц назад мы затратили на похожую задачу 4 часа, два месяца назад 3 и ещё три месяца назад сделали похожую задачу за 5 часов. В таком случае оценка задачи в 4 часа выглядит как будто бы адекватной, но на самом деле при такой оценке любое непредвиденное обстоятельство приведёт к срыву всех сроков. Поэтому оценивать надо не по среднему, а добавлять, скажем 10%. То есть оценивать в 4 с половиной часа. В итоге большинство задач будут завершаться раньше срока, но набежавший запас неиспользованного времени пригодится в случае какого-нибудь факапа. В итоге разработчик может потратить на какую-то задачу в несколько раз больше времени, чем было отведено, но при уложиться в сроки в рамках спринта.
В целом, конечно, такая система не лишена изъянов. Но тут у меня встречный вопрос: а каком макаром все перечисленные проблемы могут решить сторипоинты?
Сторипоинты - это оценка сложности, и бывает так что задачу на много стрипоинтов удается решить за пол дня, только потом пол дня все равно уже ничего сделать не получится.
Поэтому и оценивают количество сложности, котрое переваривает команда в неделю, и это позволяет достаточно точно строить поаны и анализировать.
В часах оценка плоха тем, что всегда есть куча активности, которая двигает процесс в целом - например - ответить на вопрос коллеги, но к конкретной задаче не относится. Короче я не видел чтобы хоть раз оценка в часах нормально работала и не приводила к бесплатным овертаймам или вопросам - а почему на это ушло столько часов
Я уже четвёртый год работаю без каких-либо овертаймов, при этом всё измеряем в часах. Чтобы оценка нормально работала, всегда нужен запас. Если я даю оценку три часа, значит я справлюсь за три часа, но проджект всё равно ставит 5.
ответить на вопрос коллеги
Если вопрос очень объёмный, нужно залогировать потраченное время в задачу коллеги. Ну или спросить у проджекта, куда его логировать.
а почему на это ушло столько часов
В случае непредвиденных сложностей нужно сообщать проджекту, как только эти сложности появляются. Плюс нужно собрать всю информацию, которая поможет клиенту понять, что проблема действительно непредвиденная: ссылки на спецификации, issue к библиотекам, скрины с пояснениями и т.д.
Поэтому и оценивают количество сложности, котрое переваривает команда в неделю
В часах это ещё проще: количество людей умножаешь на 40. На самом деле сторипоинт - это человекочас, умноженный на производительность сотрудника. Условно, 1 сторипоинт = 1 час мидла = 2 часа джуна = 30 минут сеньора. Но в таких единицах есть необходимость только когда у членов команды сильно разная производительность и непонятно, кто какую задачу будет делать. Если же в команде до 10 человек и проджект хорошо знает каждого разработчика, то можно смело оценивать в часах, зная наперёд, кто именно будет делать эту задачу.
Я уже четвёртый год работаю
А я 12 лет. Вы специфику работы указывайте хотя бы, когда своими рассужденимяи делитесь. Так сказать, граничные условия, в которых это всё работает. Вы 1С-франчайзи, веб-студия, работающая с CMS, или другого сорта галера, в которой все задачи идентичные и вы делаете одно и то же годами для разных заказчиков? Да, для вас такая схема подходит.
Для продуктовой же разработки, когда каждый спринт придумываются фичи, которых внутри данного продукта ещё не было, ваши рассуждения не применимы.
12 лет
А мне почти 40. Ловко я цифру из контекста выловил, да? У вас приёмчик подсмотрел. "Четвёртый год работаю без овертаймов", но перед этим ещё 5 с периодическими овертаймами и ещё 8 вне IT.
заставить разработчика постоянно испытывать стресс за "неверно выставленные сроки"
Я такого нигде не предлагал, вы сами это выдумали. Сроки - это проблема только менеджмента. Я пишу о том, что менеджмент должен советоваться с разработчиками о сроках, но советоваться - это не значит перекладывать ответственность.
Специфика, если вам интересно: годами делаю разные задачи для одного заказчика.
Ловко я цифру из контекста выловил, да?
Я не собирался вырывать из контекста. Ваш комментарий в моём представлении соответствует тому, что может написать человек с 4-мя годами опыта на одном месте. Но тот факт, что вам ближе к 40, также объясняет вашу категоричность.
Вы рассуждаете, будто видели всю разработку изнутри, но создаётся впечатление, что вы работали всё время в одной и той же компании, и не видели других способов организации работы. Например, в этом комментарии вы говорите, что работаете в веб-студии. Кстати, это всё-таки означает, что вы работаете с разными заказчиками.
Ссылка на комментарий некликабельная, не могу понять, о каком комментарии идёт речь. Я занимаюсь веб-разработкой, но не работаю в веб-студии. Я работаю в аутсорсинговой компании и в последние два с половиной года я работаю только на двух проектах для одного клиента. Хотя вам, конечно, виднее.
годами делаю разные задачи для одного заказчика.
Я работаю в аутсорсинговой компании и в последние два с половиной года я работаю только на двух проектах для одного клиента.
Во-первых, это подтверждает моё предположение о том, что вы работаете в аутсорсе, отсюда ваша необходимость логировать время и отчитываться за каждый час. Как я писал выше, к счастью, далеко не все мы вынуждены работать таким образом, поэтому ваши рассуждения применимы только для ваших коллег-аутсорсеров.
Во-вторых, не могу не обратить внимание на то, что во всех ваших комментах разный опыт работы в той или иной роли, поэтому боюсь, ваш реальный опыт не ясен не только мне, но и всем читающим.
PS ссылку проверил, рабочая.
Не знаю, что именно вы хотите мне доказать, но пока что я вижу только то, что вы не понимаете разницу между веб-разработкой и веб-студией и на основании этого заблуждения зачем-то пытаетесь делать какие-то выводы обо мне лично.
PS ссылку проверил, рабочая.
Ссылка заработала после того, как вы отредактировали свой комментарий.
Вот эту цитату из вашего комментария:
Например, в этом комментарии вы говорите, что работаете в веб-студии
я специально оставлю здесь, на случай если вы опять отредактируете и будете говорить, что имели в виду другое.
Так я действительно не понимаю. Уж простите, но для меня любое место, где надо логировать время - это галера. Я в таком работал в начале карьеры, но искренне надеюсь, что больше в такие условия не попаду. Зарекаться, конечно, не стоит, поэтому я говорю, что надеюсь.
И вы виляете, как уж, прикапываясь к формулировкам, лишь бы уйти от основной мысли, которую я хочу до вас донести: не все тут работают как вы. Поэтому ваши рассуждения неиприменимы ко всей отрасли.
К этой мысли есть претензии? Может, я некорректно использовал слово "отрасль", а следовало использовать "профессиональное сообщество", например?
Вы настолько неумело жонглируете терминами, что от меня ускользает мысль, которую вы хотите сказать.
Веб-студия - это маленькая организация, которая занимается созданием простых сайтов под ключ. Там проекты уровня "бюджет 1000$ и срок месяц". Один проект там как правило делает один программист, поэтому командной работы как таковой нет, а управление проектами крайне примитивное. Вы почему-то сделали выводы, что я работаю именно в веб-студии, хотя в моём комментарии, приведённом вами же по ссылке, я называю порядок стоимости обслуживания проекта, на котором работаю и такой бюджет несовместим с понятием веб-студии.
Галера на айтишном жаргоне - это крупная аутсорс-компания. И вы очень зря пренебрежительно относитесь к ним, потому что в любой галере проджект-менеджмент априори должен работать лучше, чем в продуктовой компании. Если галера зафакапит сроки, их клиент просто наймёт другую галеру. Если же продуктовая компания зафакапит сроки, то просто перенесут релиз на попозже.
Что касается сложности проектов и квалификации разработчиков, то нет никакой разницы между продуктом и аутсорсом. Во-первых, многие продуктовые компании отдают отдельные фичи на аутсорс. Во-вторых, аутсорс-компании могут работать с проектами, которые крупнее и сложнее многих продуктов. В-третьих, есть небольшие продуктовые компании, в которых вообще нет своих разработчиков.
Поэтому ваши рассуждения неиприменимы ко всей отрасли
Уметь правильно оценивать задачи в часах - это очень сложно, и многие не могут этому научиться. Естественно, мои суждения неприменимы там, где не умеют оценивать задачи, и это очень большой кусок отрасли. И меня в целом очень расстраивает, что вместо того, чтобы признать важность и сложность проблемы, происходит инфантилизация IT-сообщества и придумываются всякие детсадовские понятия вроде сторипоинтов
Ну вот вы и изложили по пунктам ваше пренебрежительное отношение ко всем, кто посмел работать не так, как вы, а также раздутое самомнение, которое я заподозрил у вас с самого начала.
придумываются всякие детсадовские понятия вроде сторипоинтов
Да-да, мы в своих фаангах детсадом занимаемся, а вот на галерах люди действительно знают, как надо работать. /s
Я, конечно, не преуменьшаю того факта, что вы, вероятно, работаете на износ и гораздо интенсивнее меня. Но мне всё-таки не кажется разумным распространять на всех формат, где "мерилом работы считают усталость".
Как я говорил выше, я поработал и в таких условиях, как вы, и в детсаду со сторипоинтами. Как-то так получается, что в детсаду я выполняю гораздо более интересные и масштабные задачи, которые просто бесполезно оценивать в часах. Вы либо декомпозируете задачу на 40 штук, что само по себе бред, либо у вас будут оценки по 40 часов, что тоже не сильно информативно.
вы
ваше
Мне не очень нравится то, как вы ведёте дискуссию. Я рассуждаю о проджект-менеджменте, а вы рассуждаете обо мне лично и моём лично опыте работы. В который раз делаете обо мне какие-то предположения и ставите эти умозаключения мне в упрёк. Я бы советовал вам ещё раз перечитать нашу дискуссию и сделать какие-то выводы о своём стиле общения.
вы, вероятно, работаете на износ
И вновь мимо. Я не работаю на износ по двум причинам. Во-первых, я умею корректно оценивать время выполнения задач. Во-вторых, я умею выполнять эти задачи достаточно качественно и быстро. И моё высокое самомнение (чего уж скрывать, оно действительно такое) основано исключительно на результатах моей работы и на отзывах о ней моих коллег и клиентов.
в детсаду я выполняю гораздо более интересные и масштабные задачи
Вы не открыли Америку. Я думаю, если вы опросите тысячу человек, где им было интереснее - в детсаду или на работе, то все дружно ответят, что в детсаду было интереснее.
А мне нравится, когда человек первым комментом к статье пишет
Чушь полная.
Сверху поливает это фразами, типа
происходит инфантилизация IT-сообщества и придумываются всякие детсадовские понятия
А потом удивляется, почему ему напихали полную панамку и предъявляет всем за стиль общения. На себя посмотрите.
И моё высокое самомнение (чего уж скрывать, оно действительно такое) основано исключительно на результатах моей работы и на отзывах о ней моих коллег и клиентов.
Господа Джастин Крюгер и Дэвид Даннинг понимающие вам улыбаются.
С Даннингом-Крюгером у вас та же история, что с веб-студией, лучше перечитайте определение, прежде чем сыпать терминами. Эффект Даннинга-Крюгера не может быть применим там, где самомнение строится на основе оценок окружающих.
Да ну? И где такое сказано в определении? Вижу указание на компетенцию. Увы, если ваши коллеги обладают сходным с вами уровнем компетенции, эффект применим к вам в совокупности - вы просто не знаете, что может быть как-то по-другому. Ну либо вы подвержены другому искажению и не замечаете критики в свой адрес.
В целом, если вам кажется, что обладая вашим опытом, вы досконально разобрались в профессии и можете так категорично раздавать советы - это звоночек.
Давайте попробую подвести небольшой итог дискуссии. Значит я назвал фразу "Оценивать в часах бессмысленно" чушью, аргументировав своё решение рядом примеров из личного опыта. В ответ от вас я лишь услышал, что у меня голова засунута в песок, у меня мало опыта, я работаю в плохой компании, где плохо относятся к сотрудникам. А также что в целом моя квалификация оставляет желать лучшего, равно как и квалификация моих коллег. При этом я на 200% уверен, что вы не знаете лично ни меня, ни моих коллег, не знаете, где я работаю, а если бы и знали, всё равно ничего бы не знали об этой компании.
В общем, не вижу ни малейшего смысла продолжать разговор с вами.
аргументировав своё решение рядом примеров из личного опыта
А я в ответ пытаюсь вам донести, что ваш личный опыт не распространяется на всю индустрию. Мысль, от обсуждения которой вы уходите всеми возможными способами, попутно обижаясь, что с вами грубо общаются. При этом не стесняетесь всем остальным рассказывать, как неправильно они работают и вообще "устраивают детский сад".
Да, на этом и закончим.
самомнение строится на основе оценок окружающих.
Помнится, я что-то такое читал, там было что-то про короля и патье...
но для меня любое место, где надо логировать время - это галера.
тот факт, что вам ближе к 40, также объясняет вашу категоричность
И у кого тут категоричность)
в любой галере проджект-менеджмент априори должен работать лучше, чем в продуктовой компании
You would think, но на самом деле нет. Галеры закладывают столько оверхеда в цену для клиента, что плюс-минус год разработки вообще ни на что не влияет. Особенно в тру галерах, где кучи людей на бенче, которых во-первых надо кормить, а во-вторых всегда можно призвать в усиление если команда не осиливает, и где куча продажников у которых единственная цель это сделать так чтобы клиент с ними остался на подольше, и она в том числе включает в себя оправдание долгих сроков.
А вот точная оценка сроков выполнения в этом мире дело вторичное уже.
Галеры закладывают столько оверхеда в цену для клиента, что плюс-минус год разработки вообще ни на что не влияет.
Так это и есть показатель хорошего менеджмента - взять с клиента максимально возможную сумму за то, чтобы сделать минимум работы. Другое дело, сколько из этого оверхэда дойдёт до карманов разработчиков, но для этого и придумали отзывы работников о компаниях
Вот поэтому лично я и не хочу больше связываться с галерами. С одной стороны, с клиента дерут максимум денег, с другой, с разработчика требуют уложиться в минимальные сроки, заставляя логировать каждый час времени. Это какое-то круговое очковтирательство, где никто из участников не может адекватно ответить, что происходит.
Вот у вас здорово, что не поверни все хороший менеджмент. Знают сколько займет разработка - очень хорошо, понятия не имеют - так еще лучше.
Плохой менеджмент - это когда есть недооценка стоимости и/или недооценка сроков, а клиент при этом не хочет платить и/или ждать, потому что это приводит к овертаймам у сотрудников и/или финансовым потерям компании.
Если же менеджмент называет завышенную оценку, но в рамках того, что клиент готов заплатить, то это хорошая сделка. Вопрос в том, что бесконечно завышать нельзя, потому что "рыночек порешает" рано или поздно.
как только эти сложности появляются. Плюс нужно собрать всю информацию, которая поможет клиенту понять, что проблема действительно непредвиденная: ссылки на спецификации, issue к библиотекам, скрины с пояснениями и т.д.
Тут иногда дополнительные часы появляются, куда их указывать?
Это совсем разные культуры. Cкорее всего - заказная разработка или продукт.
В продуктовой - нет смысла тратить время на подсчет часов и не надо ничего выставлять.
У нас, например, попусту нет проджектов (масштаб продукта - человек 50). Есть продакты, они определяют продуктовые гипотезы и бэклог. Но можно прикинуть сколько экономии ФОТ идет.
- Помогают ли сторипоинты планировать - да, конечно. Можем ли мы деливирить к дэдлайну - конечно.
Зато если разработчик понимает что фичу можно реализовать дешевле в общем он спокойно идет к дизайнеру, он обновляет макеты (и тратит может быть еще несолько часов) и все счастливы.
В история с оценками "до часов" такие коммуникации как правильно затруднены, а менеджеры не смотрят на общий оптимум трудозатрат, а только чтобы все было сделано по оценке. Ну и атмосфера как правило так себе в таких фирмах, со всей текучкой.
Если у вас продакт занимается бэклогом, то это значит, что у вас есть проджект, просто вы его назвали продактом. Единственное отличие разработки в продуктовой компании от разработки в аутсорсе - это менее строгое планирование. Но всё очень отличается от случая к случаю. Например, в стартапах атмосфера и текучка, как правило ещё хуже, чем на аутсорсе, потому что им нужны "горящие глаза". Отличие продукта от стартапа весьма условное и всё сводится к тому, сколько ещё денег осталось у владельца. Как только финансовые показатели продукта приблизятся к критическим, сразу появятся и дедлайны, и планирование, и текучка.
Продакт является источником задач стратегического уровня. Понятно что декомпозиции и согласования уже делают команды.
Продакт следит за метриками продукта.
Проджект следит за сроками, фичами и бюджетом, также рисками. За метрики он вообще отвечать не может - потому что это не его ответственность, если фича не нужна юзерам, его задача - заделиверить фичу.
Совсем разные роли.
Проджект может быть "прослойкой" между продактом и конкретной командой, но в целом не очень нужна если всего несколько команд по несколько человек, тем более - меньше прослоек - проще пересогласования, если хочется что-то упростить.
Окей. Оценил задачу в один сторипоинт. Из за вопрос коллеги потратил, условно, два. Как это спасает по сравнению с часами?
Человек не воспринимает абстракции, которые не с чем сравнить. В астрономии, например, массу объектов мерят солнечной массой, а расстояния астрономическими единицами. Потому-что это точно посчитанные величины и легко построить аналогическую абстракцию. 10 солнечных масс - это дофига. 10 АЕ - тоже не мало.
Сторипоинты даже в одной компании на разных проектах скорее всего будут разные. Это привязка непонятно чего непонятно к чему и непонятно зачем. Даже в статье сказано что поинт привязывается ко времени затраченному на самую лёгкую задачу. А сведётся всё к одному - "Вася поставил 1 поинт, это примерно 1-2 часа". Зачем тогда все эти кручу-верчу запутать хочу?
Сторипоинты - это все таки оценка сложности задачи, а не времени затраченной. Если условный Вася ставит сторипоинты и сам же собирается реализовывать эту задачу, то он способен оценить ее и в часах. Но когда в команде 5, 10 разработчиков, то у оценка в часах может отличаться. И опять 1 сторипоинт <> 2 часа, так как может быть простая задача, в которой надо кучу файлов править руками или тестов, т.е. ничего сложно, но занимает много времени, причем одинаково, что у синьора, что у джуна.
Сторипоинты - это все таки оценка сложности задачи, а не времени затраченной.
Пример сложной задачи - постоянно отваливается база с таймаутом. Надо посмотреть логи и подправить запрос. Джун не справится, поэтому напишем 100 сторипоинтов.
Пример простой задачи - ввести данные миллиона человек из церковных книг в базу. Тут всё проще некуда, поставим один сторипоинт.
Или всё-таки время выполнения как-то связано со сторипоинтами?
Зачем 100? по моему вы слишком утрируете. Сторипоинты сложно конвертировать в часы если вы об этом, но как правило, чем выше сложность задачи тем дольше она будет делаться. Чем выше сторипоинт, тем сложнее определить время, которое на нее будет затрачено, так как в это закладывается помимо объема работы, еще неопределенность, сложность и другие факторы.
Нужно учесть, что сторипоинты - это абстракции, которая может зависеть от компании (я никогда не видел задачу на 100 поинтов), не существует какого ГОСТ сторипоинт = 8 часо.
P.S. Если кто-то хочет измерять задачу в часах, то пожалуйста, команды должны работать как им удобно.
Тогда я вообще ничего не понимаю. Допустим у меня посчитано что ресурс разраба - 10 сторипоинтов в спринт. Закинут на Васю 10 поинтов. На Олега тоже. Только у Васи - 10 рефакторингов которые он когда-то оценил по поинту, но занимают они дофига времени. А у Олега очень сложная интеграция и надо перелопатить 5 страниц доки из которой станет понятно что надо вставить один скрипт на страницу и прокидывать его ответ на бэк, с чем Олег управился всего за день.
Получилось Олег всё сделал и сидит довольный, а Вася даже половины не успел. Как мне с точки зрения менеджмента планировать спринт тогда? Сложность далеко не всегда коррелирует со временем.
Получается нужно совмещать подход. Оценить и сложность, и трудоёмкость (времязатраты) задачи. И мы опять уйдём в часы. Потому-что люди работают не сторипоинтами, а часами. И заказчик ждёт не сторипоинты, а время, которое уйдёт на его заказ.
Получается нужно совмещать подход
Нет. Вам(ну или Васе) просто нужно после этого понять что рефакторинг занимает больше времени и оценивать его по другому.
То есть после каждой итерации смотреть что оценили неправильно и почему. И корригировать то, как вы оцениваете.
И мы опять уйдём в часы. Потому-что люди работают не сторипоинтами, а часами. И заказчик ждёт не сторипоинты, а время, которое уйдёт на его заказ.
Никто не работает с часами.
Разработчикам вообще ничего из этого не нужно. Они делают задачу пока она не готова.
Заказчика часы под каждую задачу тоже по хорошему не интересуют. Ему интересно сколько это будет стоить и просто чтобы было готово в срок.
Так откуда с вашими поинтами сроки то берутся??? 10 поинтов - это что? Когда будет готова задача? Если она в срок не сделана, то это чья проблема - разраб некорректно оценил и не уложился в оценку или оценку неверно конвертировали в срок?
10 поинтов - это что?
Это сложность задачи. При этом вы точно так же знаете что скажем команда в среднем делает 50 сторипоинтов в неделю.
Абстракция на абстракции. Как и в статье сказано - это измерение в попугаях. Сложность задачи и в часах можно оценить. Мне кажется суть тут просто в том чтобы оценки звучали не так страшно. 30 человекочасов - звучит дорого. А 10 поинтов - ну нормально, наверно. Всё равно эти поинты могут сконвертироваться хоть в 5, хоть в 25 часов.
Сложность задачи и в часах можно оценить
Можно. Но эти часы из оценки всё равно в большинстве случаев не будут совпадать с тем сколько времени реально будет потрачено на реализацию. То есть это точно такая же абстракция.
Всё равно эти поинты могут сконвертироваться хоть в 5, хоть в 25 часов.
Так и ваши часы из оценки точно так же могут сконвертироваться в какое-то другое количество часов в реальности.
Всё так. Потому-что риски и форс-мажоры никто не отменял. Мне было интересно чем поинты лучше часов раз их так защищают и продвигают.
Как и подозревал - ничем. Те же яйца, только в профиль. Хоть длинной члена мерить, а всё разные названия для одного и того же.
И опять возвращаемся к началу - нахрена выдумывать абстрактные единицы непонятно чего, если люди давно придумали единицы измерения? Получается незачем. В часы можно точно так же заложить и риски, и сложность, и примерные времязатраты среднего разработчика. Эта единица будет понятна даже ребёнку. А вес и понимание что такое поинт у всех своё.
Мне было интересно чем поинты лучше часов раз их так защищают и продвигают
Например потому что они не создают иллюзию того, что оцениваются действительно реальные часы.
И опять возвращаемся к началу - нахрена выдумывать абстрактные единицы непонятно чего, если люди давно придумали единицы измерения?
Потому что это примерно как мерить расстояние в миллиметрах ртутного столба.
Сложность задач не измеряется в часах или там днях. По хорошему для неё нужны собственные единицы измерения.
Не согласен. Ставлю 12 часов - значит задача сложная или рутинная и займёт много времени.
Ставлю 10 поинтов - будет означать ровно то же самое.
И манагер в обоих случаях видит, что минимум полтора-два дня по ресурсу уже занято.
Ставлю 12 часов - значит задача сложная или рутинная и займёт много времени.
Почему бы тогда и расстояние не измерять временем?
Ну то есть если ставлю 10 часов, то значит дорога длинная и займёт много времени. О каком расстоянии я говорю?
И манагер в обоих случаях видит, что минимум полтора-два дня по ресурсу уже занято
Минимум два дня? Максимум два дня? Ровно двадцать часов?
Если вы поставите сорок часов, то будет менеджер ожидать что работа будет сделана за неделю? Готовы вы ему это гарантировать?
О каком расстоянии я говорю?
Вспомните школьную программу и посчитайте, если скорость известна. Навигаторы, к слову, вам время дороги в часах и озвучивают. Пример совершенно невалидный.
Минимум два дня? Максимум два дня? Ровно двадцать часов?
Договоритесь заранее по оценкам и всё. Мы на груминге даём максимальную со всеми неизвестными. И она, естественно, может поменяться в обе стороны, если появятся новые вводные. Это проблема аналитиков или заказчика, если он меняет что-то на ходу, а не разработки.
Если вы поставите сорок часов, то будет менеджер ожидать что работа будет сделана за неделю
А Если 10 поинтов, то что? Вот вы и вскрылись - просто пытаетесь снять с себя ответственность за оценку и запутать сроки.
Но только это так не работает. Менеджер в любом случае будет ждать задачу в какой-то срок. Он сконвертирует поинты в примерные часы, как ему это видится. Иначе определить срок сдачи задачи НЕВОЗМОЖНО. Время идёт в часах. Всё. Это аксиома.
Что в это время войдёт - сложность, риски, объём и прочее уже лирика. В ваш поинт точно так же это всё будет закладываться. А если нет - я вас расстрою. У вас в целом хреновое планирование. И то в каких единицах его размечать не является проблемой.
Вспомните школьную программу и посчитайте, если скорость известна.
Так в том то и дело что скорость неизвестна. Об этом и речь.
Поэтому глупо измерять расстояние в часах. И сложность тоже.
А Если 10 поинтов, то что?
То менеджер знает оцененную сложность задачи. И ему даже в голову не придёт что эта сложность говорит о том, сколько конкретно времени займёт реализация.
А дальше он может сам думать и сколько каких задач он хочет запланировать на какое отрезок времени. Под свою ответственность.
Разработчики оценивают сложность. Менеджер планирует сроки. Это разные вещи. Зачем использовать для разных вещей одни и те же единицы измерения? Тем более если и то и другое используют в одном контексте?
Почему бы тогда и расстояние не измерять временем?
Сколько от города А до города Б?
Три дня пути
Сложность далеко не всегда коррелирует со временем.
Вот именно, стоирпоинт включает ни только объем работы, но и сложность этой работы и неопределенность. Поэтому чем выше сторипоинт, тем тяжелее переводить в часы. Вы как менеджер уже можете оценивать время при распределении задач в спринте, в зависимости от того кому она назначается.
Вася получил задачу со сторипоинт 5 - с высокой степенью неопределенности (в новом для него домене), ему нужен спринт или 2 ее сделать.
Олег получил 10 задач по одному сторипоинту, где нужно сделать мелкие изменения, ему можно еще накинуть.
Я не уверен, что линейный подход здесь будет работать - например 10 сторипоинтов на спринт для разработчика, по описанным выше причинам.
Да при чем здесь это?
Конкретно про последний параграф речь:
В часах оценка плоха тем, что всегда есть куча активности, которая двигает процесс в целом - например - ответить на вопрос коллеги, но к конкретной задаче не относится. Короче я не видел чтобы хоть раз оценка в часах нормально работала и не приводила к бесплатным овертаймам или вопросам - а почему на это ушло столько часов
Отвлёкся на сторонний вопрос и задачу в спринт выполнить не успел. Как СП здесь поможет?
Короче я не видел чтобы хоть раз оценка в часах нормально работала и не приводила к бесплатным овертаймам
В том и смысл.
А теперь вынимаем голову из песка и вспоминаем, что далеко не все IT-компании организованы по принципу галер (к нашему общему счастью).
Поэтому рассуждения на тему, как заставить разработчика постоянно испытывать стресс за "неверно выставленные сроки" и выжимать из него все соки, пока не сдохнет, оставляем себе и в приличном обществе не показываем.
Все ваши сторипоинты потом всё равно сконвертируются в часы, потому что каждый сотрудник работает 40 часов в неделю, и никак иначе.
Ну неправда же. Никто в реальности не работает 40 часов в неделю. И уж тем более не работает конкретно над задачами всё это время.
И если мерить так, то и начинаются вещи вроде "Тебе дали задач ровно на 40 часов, а сделал ты на 30! Причём здесь какие-то совещания?!"
Игнорировать тот факт, что бухгалтерия в расчётах оперирует часами, это то же самое, что заметание мусора под ковёр
Вы тут пытаетесь сравнивать тёплое с мягким.
Это же получится средняя температура по больнице
И это лучше чем никакая.
При этом вы сами написали "понятно, что каждый сотрудник может выполнить разный объём работы за эти 40 часов", но почему-то не считаете это проблемой при вашем способе учёта.
По какому сотруднику вы собираетесь измерять сколько времени нужно на задачу? По самому быстрому? По самому медленному? По среднему?
Причём здесь какие-то совещания?!
Как причём? Совещание - это такой же рабочий процесс, как и написание кода, поэтому оплачивается по той же ставке. Если я совещаюсь полдня, это значит, что на другие задачи мне сегодня надо потратить только 4 часа, а не 8. Время, затраченное на совещания, как правило, логируется в специальную задачу. И в любом спринте всегда должно быть запланировано определённое количество времени на совещания.
По какому сотруднику вы собираетесь измерять сколько времени нужно на задачу?
По тому, который будет выполнять эту задачу. А по какому ещё? Любой адекватный проджект понимает, что если задача была оценена в 1 час и планировалось, что её сделает сеньор, то если задачу планируют передать джуну, то эстимэйт нужно пересмотреть.
По среднему?
Вот тут и зарыта собака. Сторипоинт - это производительность среднего работника, умноженная на определённый коэффициент. А каждый участник команды должен иметь свой собственный коэффициент перевода сторипоинтов в часы. Условно джун сделает задачу в 10 сторипоинтов за 5 часов, а сеньор за 1. Поэтому у джуна коэффициент 2, а у сеньора 10. Но это тоже никакая не серебряная пуля, потому что 5 джунов не заменят ни одного сеньора. И начиная с определённого уровня сложности джун со сложной задачей может вообще не справиться.
Совещание - это такой же рабочий процесс, как и написание кода, поэтому оплачивается по той же ставке
Оплачивать вы его можете как угодно. Вы их учитываете как задачи? Любые совещания? Вообще любые вещи, которые не относятся конкретно к работой над задачей?
По тому, который будет выполнять эту задачу.
Но вы не знаете заранее кто её будет выполнять на самом деле.
Если совещание большое, оно учитывается, как задача. Если это звонок на 5 минут, это всё идёт в рамках текущей задачи. В этом и суть планирования - заложить в эстимэйт время на кофе, поход в туалет, зарядку для глаз, и конечно же, на доработку задачи после возврата от QA. Что такое нормальное планирование? Это когда ты берёшь задачу, оценённую в 5 часов и неспеша, в комфортном для себя темпе делаешь её за 3 часа, а логируешь 4. В итоге менеджмент доволен, что ты управился на час быстрее, а у тебя нарисовался час свободного времени. Если работать в комфортном темпе не выходит, то либо менеджмент занижает трудозатраты, либо ты не подходишь для этой работы. Но как правило, чаще вина менеджмента.
Но вы не знаете заранее кто её будет выполнять на самом деле.
Ну приехали. Это где это так планируют задачи из расчёта, что их будет делать непонятно кто? Пока задача в бэклоге, да, предсказать бывает трудно. Но если ты её берёшь в спринт, то у тебя на этот момент уже должна быть сформирована команда с определённым капасити. На самом деле не обязательно эстимэйт заточен под конкретную личность. Как правило во время планирования рассуждают с позиции "отдадим задачу одному из вот этих трёх чуваков, у которых приблизительно одинаковый перформанс". А если тебе приходится во время спринта передавать джуновскую задачу сеньору, это уже форс-мажор, причиной которого является плохое планирование.
Если совещание большое, оно учитывается, как задача. Если это звонок на 5 минут, это всё идёт в рамках текущей задачи.
А если небольшое, но их много? Кто и как учитывает эти часы? Кто и как учитывает "сходил в туалет" или "пошёл взять кофе" или "начальник задержал на пол часа"?
В итоге менеджмент доволен, что ты управился на час быстрее, а у тебя нарисовался час свободного времени.
В итоге менеджмент перестаёт тебе доверять и всегда ожидает что задача будет сделана на два часа раньше.
Это где это так планируют задачи из расчёта, что их будет делать непонятно кто? Пока задача в бэклоге, да, предсказать бывает трудно. Но если ты её берёшь в спринт, то у тебя на этот момент уже должна быть сформирована команда с определённым капасити.
Что такое "капасити" и как вы его посчитали? Почему нельзя посчитать это капасити для команды в целом?
Что вы будете делать если кто-то справился со своей задачей быстрее чем ожидалось , а кто-то наоборот?
Кто и как учитывает "сходил в туалет" или "пошёл взять кофе" или "начальник задержал на пол часа"?
Начал делать задачу в 9:00. В 9:15 отлучился на 10 минут за кофе. В 9:50 отлучился на 5 минут в туалет. Закончил задачу в 11:00. Логирую два часа. Что тут непонятного?
всегда ожидает что задача будет сделана на два часа раньше.
Менеджмент должен думать, что я сделал задачу на час быстрее, а не на 2. На самом деле, если бы я всегда логировал именно столько времени, сколько затратил, меня бы уже уволили, потому что у клиента не хватило бы на меня задач.
Что такое "капасити" и как вы его посчитали? Почему нельзя посчитать это капасити для команды в целом?
Capacity - ёмкость. Считается по формуле N * 40, где N - число участников команды. А 40 - число часов в неделе. Например, если у тебя 5 человек в команде, то капасити 200 часов в неделю. Если на среду забукан звонок на час с участием трёх человек, то капасити уже 197 часов.
Что вы будете делать если кто-то справился со своей задачей быстрее чем ожидалось , а кто-то наоборот?
Ну что за глупые вопросы? Если один сидит без задач, а второй не справляется, значит надо отдать часть задач того, кто не справляется, тому, кто без задач. Неужели это непонятно. Если же все задачи сделаны, а время осталось - сиди решай техдолг. Но в любом случае суть проджект-менеджмента сводится к тому, чтобы такого не было. У программиста цель писать софт без багов. У ПМ цель всегда укладываться в сроки. У сантехника цель, чтобы трубы не протекали. Но по факту всегда будут и баги и сорванные сроки и сорванные краны, потому что такова жизнь. И в любой профессии качество специалиста измеряется процентом факапов.
Начал делать задачу в 9:00. В 9:15 отлучился на 10 минут за кофе. В 9:50 отлучился на 5 минут в туалет. Закончил задачу в 11:00. Логирую два часа. Что тут непонятного?
Так речь то не о логировании, а о планировании.
Менеджмент должен думать, что я сделал задачу на час быстрее, а не на 2.
И там конечно одни дураки сидят.
Capacity - ёмкость. Считается по формуле N * 40, где N - число участников команды
Каким образом это поможет при планировании а вашей системе если здесь не учитываетсяс какой скоростью решает задачи каждый отдельный её член?
Если один сидит без задач, а второй не справляется, значит надо отдать часть задач того, кто не справляется, тому, кто без задач.
То есть получается что вы не можете запланировать кто конкретно будет решать какие задачи в спринте. О чем и речь.
Так речь то не о логировании, а о планировании.
По залогированному времени в ретроспективе определяется точность планирования, и все будущие планы всегда строятся на основе предыдущего логирования. Отсутствие логирования = отсутствие учёта. Опять же, если мне дадут на оценку задачу, а я делал похожую задачу месяц назад и залогировал 2 часа вместе с кофе и туалетом, это значит, что в этот раз она займёт всё те же 2 часа, и с большой долей вероятности, я снова отлучусь и за кофе, и в туалет.
И там конечно одни дураки сидят.
Если менеджмент не обвешивает сотрудников трекерами активности и видеонаблюдением, это не значит, что они дураки.
Каким образом это поможет при планировании а вашей системе если здесь не учитываетсяс какой скоростью решает задачи каждый отдельный её член?
Таким, что при более тщательной оценке капасити распадается, к примеру, на 40 джуновских часов, 120 мидловских и 40 сеньорских.
То есть получается что вы не можете запланировать кто конкретно будет решать какие задачи в спринте.
Нет, нет, и ещё раз нет. ПМ может планировать, кто будет делать какую конкретную задачу и он делает это. И в итоге большинство задач должно следовать плану. Ситуация с передачей задач от одного исполнителя другому, как правило возникает в конце спринта, что объясняется тем, что никакое планирование не является на 100% точным. Степень точности планирования, определённая в ретроспективе - это и есть показатель качества работы менеджмента.
Получается так, что планирование - это сложно, плюс планирование никогда не будет на 100% точным. Но если это сложно, это не повод от этого отказываться.
А еще там не учитываются компетенции разных членов команды.
По замыслу все разработчики там подобно роботам - все одинаковые, с одинаковыми скилами и решают задачи с одной скоростью.
Жизнь обычно несколько сложнее схем.
Да, я однажды поделил сумму сторипоинтов на сумму отмеченных часов в жире. Получилось 1sp = 8ч. Это разумеется для конкретной команды и проекта.
1sp - это, насколько я помню, была задача по добавлению поля на форму или в грид. Без бизнес логики, просто crud.
Думаю, что планирование приблизительное (пальцем в небо - типа я так вижу на данном этапе) - оно конечно в часах, потому что это надо действительно для оценки стоимости проекта.
Другое дело, что в реальности эти часы, просто часы для бухгалтера и инвестиционного комитета, который решать давать деньги или нет.
И в реальности логично оперировать попугаями, как в скраме, мол эта фича на 10 попугаев, а эта на 2. Создали полный список фич, просуммировали попугаи (получили скажем 100500), потом посмотрели, ага от нас хотят, чтобы мы сделали проект за 10 месяцев. Значит надо 10 спринтов по 1005 попугаев.
Стали делать первый спринт - получилось скорость 5025 попугаев, получается вместо 10 месяцев будем делать 20. Идем на комитет, рассказываем, что вместо 10 месяцев будем этой командой делать 20 месяцев.
Комитет уже решает, либо соглашается, ок делайте 20 месяцев, либо говорит давайте в два раза больше народу нагоним, а если денег нет, то разгоняем команду и закрываем проект.
Поделюсь своим скромным опытом наблюдения за командой: рп, разраб, аналитик и куча еще всякого народа. На совещаниях человек по 6-7. По итогу, низкий КПД, команда год проедала деньги и всех разогнали. Это, конечно, частный случай и не дает нам практику, но за этот год они попробовали много схем борьбы с атомизацией, включенностью команды, дошли до того, что пол дня занимали совещания. Оплата стояла почасовка с учетом работы над задачей, но, пользуясь этой дырой (тем, что никто никогда не знает, сколько в реальности это займет времени) команда просто ела деньги заказчика.
Поднимают программиста из анабиоза. Открывает глаза, спрашивает: какой сейчас год? 9999... скоро 10000, а тебя с сиви написано, что знаешь кобол...
Когда то я ехал в поезде с профессором, он возмущался по поводу зарплат. Я спросил у него сколько книг по профессии он прочёл за последнее время, на что он ответил, зачем мне что то читать, если если ничего нового не было с начала прошлого века. Вот по этому и такая разница в зарплате, программист учится пока работает. Каждые 3-5 лет новая мулька, не сказать чтобы сильно новая, но все же поизучать придётся.
По поводу оценки времени, если задача хорошо декомпозирована на подзадачи, проблем с оценкой нет. Для декомпозиции необходимо провести исследование и потратить 1, 2 дня иногда побольше, но иначе никак
Встречал как минимум два класса задач, которые - мягко говоря - хреново декомпозируются:
1) Мы не знаем что конкретно надо сделать. Примерно что то такое, но подробностей мы не узнаем, делайте что нибудь. Тут до прототипа никакой декомпозиции не выйдет 100%, да и потом будет гадание на чаинках.
2) Задача чисто на исследование. Но невозможно оценить, сколько займёт исследование т.к задача нетривиальная. Максимум можно заложить какие-то часы, и по их результатам либо задача решится, либо не решится. Такие задачи встречаются не очень часто, но встречаются. И решаться они могут как за 2 часа, так и за 2 недели
1) Пока неизвестно что делать - делать ничего нет смысла. Но обычно известно, что нужно сделать прямо сейчас. Да, какой эта фича будет в финальном продукте - неизвестно, но ведь и делаем мы сейчас не финальный вариант, а текущий прототип. И вот на текущую задачу-прототип время оценивается как обычно, ничего особенного в ней нет. А вот оценить время до финального варианта действительно невозможно. Но тут тоже есть решение - если каждый прототип делать так, чтобы, в принципе, его можно было выкатить в прод, то бизнес имеет возможность просто в любой момент сказать, что текущий вариант good enough и он станет той самой финальной версией фичи.
2) Исследовательские задачи можно достаточно легко оценивать, просто это будет не одна оценка а последовательность из 2-3-4 оценок: первая на то, чтобы собрать общую инфу о проблеме и существующих подходах/решениях. И эта первая оценка обычно просто фиксированная, в зависимости от объёма и/или новизны данных, обычно день или два. И вот сколько данных успеешь собрать за это время - с теми и работаешь. Вторая оценка даётся по результатам инфы собранной на предыдущем этапе и она уже будет намного более точной. Обычно двух оценок хватает, но изредка сбор данных на первом этапе показывает только то, что нужно ещё неделю продолжать собирать данные (т.е. продлить первый этап), и без этого двигаться дальше нет смысла - тогда либо задачу отменяют вообще либо мы второй оценкой получаем эту самую неделю, а через неделю сможем уже оценить сколько времени нужно на решение задачи.
Про грабли неизвестно никогда, в любых задачах кроме типовых (а типовых в нашей работе обычно намного меньше нетиповых).
А "неизвестно как" - это как раз и есть причина давать оценку итеративно, по мере роста понимания "как".
Если бизнес этого не понимает/принимает, и предпочитает иметь оценку "с потолка" вместо более адекватной - тут есть разные варианты, в зависимости от того, зачем бизнесу нужна эта оценка. Если она бизнесу нужна для принятия стратегических решений вроде "браться ли вообще за этот проект" или "какую цену выставить клиенту за этот проект", то оценка "с потолка" выполненная кем-то достаточно опытным вполне подойдёт. В дальнейшем могут потребоваться дополнительные усилия (вроде урезания фич, реализации быстро-грязно хаков или переработок) чтобы в неё вписаться и проект не стал для бизнеса убыточным. А если она бизнесу нужна с целью увеличения контроля над разработчиками и микро-менеджмента "почему задачу на 5 часов делали целых 7?!", то нужно либо завышать все оценки раза в 3 либо менять работу.
2) Исследовательские задачи можно достаточно легко оценивать, просто это будет не одна оценка а последовательность из 2-3-4 оценок: первая на то, чтобы собрать общую инфу о проблеме и существующих подходах/решениях. И эта первая оценка обычно просто фиксированная, в зависимости от объёма и/или новизны данных, обычно день или два. И вот сколько данных успеешь собрать за это время - с теми и работаешь.
За 2 дня собрал инфы на решение которое потребует месяц реализации на алгоритм.
За 4 дня собрал инфу с готовым алгоритмом который решает задачу за 2 дня c тестами.
По опыту говорю что такое реально бывает.
Бывает, знаю. Тем не менее, лучшего подхода пока нет, а этот работает достаточно хорошо (хоть и иногда вот с такими сюрпризами, да).
В одном проекте начинали как раз с этого подхода с узкими рамками на рисерч. В итоге было выбрано как казалось лучшее полуготовое решение (за неимением времени на продолжение рисерча), в краткосрочной перспективе задача закрыта, в долгосрочной перспективе я уже ушел с проекта давно, а на всем его протяжении то решение давало кучу проблем выливающихся в огромные косты бизнесу и не лучшую производительность софта.
В данный момент насколько мне известно, то решение не заменено из за слишком большой завязки на него. 2 дня сэкономили сегодня - месяцы рабочего времени слиты в унитаз на багфиксы и подпил под нее, а софт работает не так хорошо как мог (если бы было потрачено 1-2 недели на самописное решение с рисерчем), и многий функционал не может быть реализован из за этого решения. Менять его категорически нехотели так как уже влили в его поддержку кучу денег.
В итоге на моей памяти, узкие временные рамки на ресерч в итоге ни разу не работали в плюс. Калька выше из геймдева, возможно в ваших краях все по другому.
Да, бывает и такое. А ещё вполне вероятно, что "самописное решение" принесло бы ещё больше проблем в долгосрочной перспективе - и адекватно оценить вероятность такого исхода крайне сложно.
Недостатки есть у всех подходов, а серебряной пули нет. Критикуя - предлагайте другой подход, который Вы считаете более подходящим. Вариант "рисёрчим до упора сколько бы это ни заняло" уже многократно проверен на практике и признан неприемлемым для абсолютного большинства проектов (где сроки и цена имеют значение для бизнеса). Другие предложения есть? На практике их уже проверяли?
Да, бывает и такое. А ещё вполне вероятно, что "самописное решение" принесло бы ещё больше проблем в долгосрочной перспективе - и адекватно оценить вероятность такого исхода крайне сложно.
Не " вполне вероятно" а совсем наоборот, самописное решение требовало монотонной работы, но его результат был бы надежный как автомат Калашникова, так как он использовал более простой подход влоб и не тянул зависимостей. (От части его в итоге реализовали, но время на его интеграцию не давали со словами "мы на то старое решение уже Х потратили и на новое ничего тратить не будем, у нас ничего нет!", при том тестовое решение было во всем лучше.
Недостатки есть у всех подходов, а серебряной пули нет. Критикуя - предлагайте другой подход, который Вы считаете более подходящим.
Истина посередине. не давать какие то малые/сжатые сроки на рисерч, но при этом не давать картбланш на недели/месяцы, и уж тем более не соваться в воду не зная броду, те не пытаться оценивать время рисерча, пока его исполнител/ли не открыли гугл и не провели уже что то базовое дабы понимать отдаленные сроки и сложность.
А где я предлагал "оценивать время рисерча, пока его исполнител/ли не открыли гугл" или "давать какие то малые/сжатые сроки на рисерч"? Я говорил о том, что вместо выдачи задачи на рисёрч с открытыми сроками нужно поделить её на этапы, и устанавливать срок на следующий этап по результатам предыдущего.
Т.е. вместо того, чтобы отправить разработчика гуглить без каких-либо сроков ему выдаётся на это два дня. Через два дня он должен быть в состоянии либо выдать результаты и прогноз сроков на следующий этап (которым может быть уже не гугл всего подряд по теме, а более глубокое исследование/сравнение двух-трёх найденных на первом этапе решений/подходов), либо сообщить что прогресса за эти два дня нет и мы по-прежнему не имеем вообще никакой конкретики. В последнем случае ему либо выдаётся ещё пара дней, либо задача передаётся кому-то более квалифицированному, либо задача возвращается в бэклог (с планами вернуться к ней когда-нибудь в будущем).
При таком подходе у бизнеса есть контроль над сроками. Время выделяемое на исследование может при этом быть сколь угодно большим, но оно выделяется небольшими итерациями, и бизнес может контролировать соотношение прогресса исследования и затрат времени, с возможностью отменить задачу после любой итерации либо принять решение использовать текущие результаты исследования (возможно не финальные-идеальные, но считающиеся good enough).
Зачастую рисерч просто так на этапы не поделить, бывает black box и на выходе когда то что то будет, а может времени не хватило, и не будет, и этапов нет, оно пока либо совсем никак не работает, а может быть завтра заработает.
Кроме того, подход с дроблением вносит бюрократию, много бюрократии... В вебе можно забить на это и тратить часы впустую на очередные отчеты дейлики и жиру, но работая с +-идейными/скиловыми людьми, они быстро выгорят от бесконечных очередных созвонов и вытягивания речей почему надо на рисерч еще и еще время. Звучит смешно но я знаю уйму поистине талантливых людей которые бежали от менеджмента бизнеса. Сроки, канбан и менеджмент это давление как ни крути, и под ним идейные и талантливые люди редко выживают, а те что остались, не часто решают проблемы.
Вот и выходит что бизнес думает что имеет контроль и сроки, а на деле там программисты кидают d4, и бизнес получает шанс реализовать фичу либо вообще никак, либо плохо, либо хорошо если повезет. И если в вебе есть тысяча фреймворков и отрисовать кнопку плохо это сложная задача, то в том же геймдеве что ни задача то очередной рисерч на N недель, и если бизнес хочет решенную задачу и хорошо, то он ждет сколько надо, а если не ждет то и задача не решается, а в таком раскладе без бюрократии и сроков - банально быстрее и проще.
Не-а. На этапы поделить можно всегда.
Если разработчик не может на этапы поделить и рассказывает "когда то что то будет, а может и не будет" то это называется недостаточная квалификация и никаких важных/сложных ресёрчей ему пока поручать нельзя (можно только простые/не критичные, чтобы он учился делать ресёрчи).
Эта бюрократия называется рабочий процесс, и без неё, к сожалению, будет ещё хуже - разработчики уйдут в себя, будут что-то делать, но что именно и когда оно будет готово не будет знать никто, включая самих разработчиков. Так уже работали, много работали, и пришли к выводу что ничем хорошим (для проекта и бизнеса) это не заканчивается, после чего и появилась вся эта бюрократия.
Бесконечные созвоны - это когда в компании не умеют ни в процессы/бюрократию ни в разработку. Обычно часового созвона раз в неделю для синхронизации между командами плюс нерегулярных созвонов внутри команды исключительно по необходимости и часто 1-на-1 - хватает. И никто от такого не выгорает.
Талантливым и идейным обычно это все мешает не настолько критично. А вот любителям развести на проекте удобный только лично им бардак и хаос, плюс ненавидящим любую форму контроля над ними - да, критично. Но такие и пусть бегут - от них обычно всё-равно никаких предсказуемых результатов получить не удаётся, работать в команде они не умеют, а те "гениальные" проекты, которые они способны реализовать самостоятельно в наши дни не особо интересны, потому что во-первых они очень маленькие и во-вторых их может поддерживать и развивать только их автор - и какими бы реально классными эти проекты ни были эти организационные недостатки перевешивают все плюсы. Поэтому желающих оплачивать этим талантам их разработки обычно не находится, и им остаётся только писать эти проекты за свой счёт и выкладывать на гитхаб.
ЕслАи разработчик не может на этапы поделить и рассказывает "когда то что то будет, а может и не будет" то это называется недостаточная квалификация и никаких важных/сложных ресёрчей ему пока поручать нельзя (можно только простые/не критичные, чтобы он учился делать ресёрчи).
Еще раз напомню про геймдев в моих примерах. В вебе в котором вы можете работать, да квалификация, а в геймдеве особенно в сложных направлениях, все примерно как в науке или медицине. Что то исследовано, но 99% не исследовано, и можно нанимать лучших прогеров мира, но они так и будут говорить что задача займет от часа и до полугода, +-.
Эта бюрократия называется рабочий процесс, и без неё, к сожалению, будет ещё хуже - разработчики уйдут в себя, будут что-то делать, но что именно и когда оно будет готово не будет знать никто, включая самих разработчиков. Так уже работали, много работали, и пришли к выводу что ничем хорошим (для проекта и бизнеса) это не заканчивается, после чего и появилась вся эта бюрократия.
Да работали, и ввели бюрократию, и к чему же оно привело в геймдеве? Day 0 патчи, провальные релизы, абсолютно постные AAA игры с реюзом технологий и ассетов (рисерчи не надо делать если ты взял весь хлам со с прошлого проекта, привет асасинам, фаркраям, fifa и еще целому списку игр.) Да масштабы выросли, но не только игр, но и проблем в играх. Инди сцена сейчас на взлете.
Талантливым и идейным обычно это все мешает не настолько критично.
Я лично знаю несколько людей которые работали в крупнейших студиях (и не в рф в том числе) и успешно сбежали с этих студий банально из за бюрократии, созвонов и тасков с оценками. При том некоторые имеют очень успешные личные проекты, которые буквально кормят их пока они сидят на диване и изучают новые технологии и варианты решения интересных им задач.
Но такие и пусть бегут - от них обычно всё-равно никаких предсказуемых результатов получить не удаётся, работать в команде они не умеют,
А вот и мой пример =) написанные мною техники с долгим рисерчем, работают без каких либо проблем. никаких других вариантов у того работодателя нет, все что они сами делали работает хуже и дает не такой качественный результат. Вот такой вот убежал, за забором никаких очередей не оказалась, дорабатывать настолько сложные и масштабные техники некому, написать с нуля те же зазаборные их не могут, а возвращаться в эту духоту даже по верху рынка желания нет.
Добро пожаловать в геймдев, тут вам не рисерч на перекрас кнопки и смену порта докер контейнера, тут приходится реально работать.
Логика "эффективного" менеджера )
Если задача неизвестна - создаём задачу-прототип, а с непонятками разберёмся позднее.
А если прототип уже сделан - значит тут и так всё понятно, просто немного доделать и в продакшен
Не, "эффективные" менеджеры - это про другое, и там всё намного-намного хуже.
Первое действительно норм. Бизнес довольно часто сам не знает, чего он хочет - просто потому, что это всё вообще "хочет" не он, а ЦА, а что именно хочет ЦА выяснить без прототипа невозможно (ну или просто непонятно как либо ещё дороже чем прототип сделать). Поэтому делаем прототип, даём пощупать ЦА, получаем обратную связь, и повторяем.
А вот второе - это реально беда, согласен! Когда бизнес воспринимает прототип как что-то рабочее, что можно в прод… А он почти всегда воспринимает именно так. Я для себя нашёл "выход" из этого порочного круга в том, что я даже прототипы не пишу быстро-грязно. Да, где-то какие-то углы и крайние случаи в прототипе срезаются, но даже в таких местах я предпочитаю чтобы сервис громко упал или хотя бы отрепортил метрику (которая обязательно приведёт к алерту) если такой "нереализованный" случай всё-таки произойдёт. Приходится искать баланс между тем, что, с одной стороны, это вроде как прототип и "вылизывать" его смысла нет потому что этот функционал может быть выкинут/заменён, а с другой стороны этот прототип в любой момент может оказаться основным продакшном на долгие годы. В общем, делаю всё возможное, чтобы даже прототипы было легко поддерживать и развивать, стараясь жертвовать какими-то другими характеристиками ради скорости разработки но не этой. Если такой возможности нет и какую-то часть всё-равно (другие команды) напишут быстро-грязно - я стараюсь её хотя бы изолировать максимально.
Насчет ресерчей совсем не согласен, буквально вот занимаюсь исследованием CJM юзеров через эмбендинги последовательностей поисковых запросов, и такой ресерч может занять от двух дней до года, два дня если первая выбранная методология дала какие-то результаты прям сразу сходу на микро данных (мы не знаем какие результаты вообще хотим получить и возможно ли их в целом получить, на момент начала мы даже не знали что исследуем CJM юзеров, это просто была идея а вдруг там что-то есть) и год если ты пробуешь первую, результатов нет, придумываешь/ищешь другую, результатов нет, потом еще 10 , потом комбинируешь их между собой, пробуешь на других данных (а вдруг дело в том что надо подать не 3 миллиона строк а 300 и тогда все сложиться), или вдруг надо запариться и лучше обработать исходные данные и тогда будут результаты, или прикрутить туда еще последовательности категории товаров, а может обучить на поисковых запросах, зафиксировать пространство и как-то выкинуть туда категории, а потом уже накидывать кластеризацию а результатов все еще может не быть. Получается пространство огромной размерности условно 200 гипотез как разные комбинации параметров ресерча, и сработать может первая, а может двухсотая, при том чем дальше нет результатов тем больше ты параметров добавляешь и тем больше расширяется пространство гипотез
Безусловно, в бигтехе есть R&D отделы в которых заниматься такими исследованиями вполне нормально. Но здесь в обсуждении речь шла о вполне обычных задачах обычных компаний. Эти задачи довольно часто тоже содержат в себе элементы с высокой неопределённостью, которые требуется исследовать перед тем как садиться писать код в продакшн. И вот в таких компаниях и на таких задачах нет возможности сказать проджект-менеджеру или тимлиду "может сделаю за пару дней а может займёт год, всё, я пошёл работать, и не дёргайте меня в ближайший год больше". Поэтому от разработчика требуется итеративно (раз в несколько дней) обновлять статус (какие перспективы и варианты уже понятны, что планирует исследовать следующим) и оценку (сколько времени займёт следующий этап и/или всё в целом) - чтобы бизнес имел возможность в любой момент принять решение нужно ли продолжать это исследование или оно стало неприемлемо дорогим, и нужно ли делать задачу одним из уже найденных подходов или лучше отменить всю задачу вообще.
О! Я как раз такую исследовательскую задачу на железе делал. Сам её написал, сам себе назначил, сам неделю наслаждался любимой работой на микроконтроллере. Типа: оценить насколько сильно МК будет загружен при выполнении вот таких задач одновременно. Подсчёт тактов и микросекунд, всё как я люблю.
Заодно поигрался рисованием всякой фигни на дисплее. Всякие эффекты примерно как мы делали на Спекки в своё время.
> Вот по этому и такая разница в зарплате
А курьер почему больше профессора получает? Потому что постоянно учит новые маршруты на райончике получается?
Бизнесу глубоко плевать учитесь вы или не учитесь если задача выполняется. Так получилось что сейчас цифровые сервисы приносят бизнесу огромные деньги, а для их создания нужны программисты. Вот и все. Которые еще и работать на зарубеж могут через Интернет, в отличие от скажем инженеров. И соответственно бустить тем самым планку зарплат.
Специальностей, в которых надо постоянно изучать что-то новое, достаточно. Та же медицина. И учить там надо намного больше информации, чем фронтэндеру.
Та же медицина. И учить там надо намного больше информации, чем фронтэндеру.
Всё это учится на этапе обучения. Далее если что-то новое и появляется/внедряется, то проходят годы исследований и согласований. Всё это давно изучено, давно описано и ничего кардинально нового там не появляется.
Хватит уже рассказывать байки про то, как много учатся в других областях. Я прихожу к взрослой-тетке терапевту в поликлинику с ярко выраженной болью в органах, в определенном месте, а она мне выписывает анальгин и не в состоянии даже предположить, что та может болеть. Учатся они, плять. Нихрена они там не учатся.
Атишка - самая мозговыносящая сфера, где среднечковый мидл по объему знаний и трудозатрат тянет на компетенцию профессора.
> а она мне выписывает анальгин и не в состоянии даже предположить, что та может болеть
Плохой или выгоревший специалист запросто может работать в любой сфере. IT не исключение. Людей, которые только вредят, или в лучшем случае выполняют задачу с которой справится уборщица, за неадекватные для такого труда деньги, везде хватает.
> то проходят годы исследований и согласований
К примеру в последнее десятилетие полностью поменялась концепция лечения гепатита С, достаточно распространенной болезни. Если раньше это было дорого, долго и без надежного результата, то теперь это в подавляющем большинстве случаев сводится к подбору не очень дорогого препарата. Врачи тут же поделились на тех, кто изучает новое самостоятельно и в курсе современных концепций лечения, и тех кому в 90м году говорили что гепатит С фактически неизлечим. При этом первые еще и вставали перед моральной дилеммой - лечить пациента по устаревшей официальной концепции, или же рассказать ему где можно купить необходимый для лечения современный препарат до того, как он получил разрешение местных властей (что часто занимает годы).
Ну можно сказать подумаешь, сложно что ли это запомнить. Но ведь врачу общей практики надо держать в голове далеко не один десяток заболеваний. Нужно быть в курсе, например, что болезни тоже мигрируют, и заболевания, бывшие в вашем городе исключительно редкими 20 лет назад, сейчас встречаются уже на порядки чаще, в следствие возросшего туризма с последующим заносом нехарактерных для региона заболеваний, и изменений климата.
К примеру в последнее десятилетие полностью поменялась концепция лечения гепатита С
Десятилетие, Карл! И ещё пару десятилетий она будет жить и применяться. Сравните с айти, где каждый год появляется очередная старая-"новая" срань, досконально разбираться в которой ты просто обязан если хочешь оставаться на плаву на рынке труда. Т.е. можешь конечно и дальше пилить проект например на Java 15, и он даже отлично будет работать. Но фактически ты уже нетрудоустраиваем на современном рынке.
За последние двадцать-двадцать пять лет появилось несколько новых вариантов лечения кератоконуса. А в старых поменялись медикаменты, инструменты, подходы.
И это одна единственная болезнь. А если взять все вещи, которыми занимается окулист?
А если учесть влияние других органов и/или болезней на глаза?
За последние двадцать-двадцать пять лет появилось
Божемой! В айти за последние 20-25 лет проще по пальцам перечислить что осталось, чем появилось! Что тут спорить, айтишнику приходится переучиваться гораздо интенсивнее чем врачу. Притом такой "отставший" врач работу всё равно найдёт. Айтишник - чуток отстал на текущей работе - и уже серьёзные проблемы с трудоустройством!
А если взять все вещи, которыми занимается окулист?
Отличное замечание! Окулист! Этот окулист случайно внагрузку не стал ещё заниматься проблемами ЖКТ и опорно-двигательного аппарата? В айти - стали! К бэкенду фронтенд. А теперь ещё и девопсинг.
Правильно выше сказали. Трудозатраты в современном айти просто не оправдывают таких денег которые платят. Исключения конечно есть когда кому-то где-то удалось затесаться и на чиле не париться... До ближайшего увольнения-сокращения...
В айти за последние 20-25 лет проще по пальцам перечислить что осталось, чем появилось
Ну расскажите например что нового появилось у людей, которые пишут на коболе.
При этом не забывайте что я написал про одну единственную болезнь. Сколько их всего у окулиста.
Айтишник - чуток отстал на текущей работе - и уже серьёзные проблемы с трудоустройством!
Какие проблемы, вы о чём? Легаси много где надо пилить. Ну задачи будут скучные, ну зарплата не такая высокая. Ну так и врача примерно то же самое.
! Окулист! Этот окулист случайно внагрузку не стал ещё заниматься проблемами ЖКТ и опорно-двигательного аппарата?
Так вот именно что стал. То есть например есть Uveitis. Очень неприятная штука. Проявляется на глазах. Причины могут быть где угодно в организме. И таких болезней тоже не мало.
Трудозатраты в современном айти просто не оправдывают таких денег которые платят.
Вы вообще о чём? Подавляющее большинство знакомых мне айтишников тратят на работу ровно свои 40 часов в неделю. А то и меньше. Никаких пет-проектов. Никакого обучения вне рабочего времени и уж тем более за свой счёт. Какие у них трудозатраты?
Какие проблемы, вы о чём? Легаси много где надо пилить. Ну задачи будут скучные, ну зарплата не такая высокая.
Ну тут можно поспорить по всем пунктам.
"Пилить легаси" (и что вы понимаете под легаси) часто заключается в том, чтобы понять как оно работает и оптимизировать. При этом не порушив ничего вокруг. Это очень нетривиальная задача и совершенно не скучная.
Легаси много в банках. Причем, реального легаси - банки живут по принципу "работает - не трогай" и если потребовалось этот легаси пилить, значит на то есть очень веские причины (обычно это оптимизация, иногда - изменение бизнес-логики). А с деньгами там, в отличии от того же геймдева, к примеру, все не так плохо - в свете последних "событий" з/п не только не уменьшились, но и увеличились (бывает что кратно) и продолжают стабильно расти.
Ну и ничего страшного в легаси не вижу если честно.
Ну тут можно поспорить по всем пунктам.
Вы не по тем пунктам спорите. Речь о том что если всё время только пилишь легаси, то количество новых вещей, которые надо учить, достаточно обозримо.
В условном коболе за последние 25 лет мало что изменилось. Тем более вот так чтобы совсем принципиально. Однозначно не больше чем в офтальмологии.
П.С. А деньги да, их и в случае с легаси иногда неплохо платят. В отдельных случаях даже совсем неплохо. Но в среднем за легаси платят меньше. По крайней мере у нас.
Ну расскажите например что нового появилось у людей, которые пишут на коболе.
Отличный черри-пикинг! Подсказать что появилось нового у писавших на мейнстримовых тогда MFC и Visual Studio 6.0? Кроме каких-то базовых принципов, программист заново переучился за 25 лет! Знания окулиста же дополнились новыми методами лечения, а вся солидная база и опыт остались незыблемы.
Какие проблемы, вы о чём? Легаси много где надо пилить.
На легаси своих дедов хватает. Плюс легаси имеет неизбежную тенденцию быть переписанным. Работать на сокращающемся рынке - удовольствие для любителей острых ощущений. Врач же таких проблем не имеет в принципе.
И таких болезней тоже не мало.
Искать первопричины - не решать проблемы других узких специальностей. Далее, врач не занимается research. Ему достаточно внимательно ознакомиться с guides и papers. Современная доказательная медицина это вообще лечение по методичке. Ломать голову приходится только в тех % которым не повезло излечиваться доказательной медициной.
Какие у них трудозатраты?
При первом же увольнении-сокращении и выходе на рынок труда, узнают очень много нового о трудозатратах, какими они должны [были] быть.
Отличный черри-пикинг!
Это пример. Но я точно так же знаю людей, которые сидят в эмбеддеде и двадцать лет пишут одно и то же на C. Или людей, которые до сих пор пишут бэкенд на восьмой Java . И список можно продолжать и продолжать.
Кроме каких-то базовых принципов, программист заново переучился за 25 лет! Знания окулиста же дополнились новыми методами лечения, а вся солидная база и опыт остались незыблемы.
Вы сами то прочитайте что написали. У программиста осталась база, а остальное пришлось учить и у окулиста осталась база, а остальное пришлось учить. В чём разница то?
Искать первопричины - не решать проблемы других узких специальностей.
Точно так же как и средний бэкенд всё равно не будет специалистом по фронту и наоборот. Конечно бывают исключения, но они точно так же есть и у врачей, которые совмещают несколько специальностей.
Современная доказательная медицина это вообще лечение по методичке
Точно так же как современное программирование это копипаста со стэковерфлоу.
При первом же увольнении-сокращении и выходе на рынок труда, узнают очень много нового о трудозатратах, какими они должны [были] быть.
Или скорее просто точно так же найдут себе другую контору с легаси и будут пилить его и дальше.
Абсолютно ничего не поменяется. Разработик на Java 15 просто за пару часов прочитает, какие вопросы задают по актуальным версиям JVM и получит оффер. Вот если он последние 10 лет пилил монолит на Java 8 и не слышал ничего о микросервисах, то тогда да, с трудоустройством могут возникнуть проблемы.
Ну, знаете, так можно сказать "Прихожу я к проргаммисту, а он пузырьком сортировать не умеет, нихрена они там не учатся". Составление статистики по одному случаю это процесс увлекательный, конечно, но не очень полезный.
Вообще-то профессор он не читать новые книги должен, а писать :)
почитай про такой великолепный проект как ITER
Один мой знакомый профессор философии, будучи ещё студентом-физиком, раздал все книжки со словами "чукча не читатель, чукча писатель".
Получает сейчас больше, чем я зарабатываю (впрочем, я в богоспасаемой, а он - в недружественной).
Я делаю так: даю задание, спрашиваю про сроки. Начинают закатывать глаза, говорить что-то типа "нуууу, к лету в лучшем случае сделаем и то не факт". Беру аутсорс. 6 часов и готово. Урезаю премии. Опять даю задание. Глаза уже не закатывают, говорят "нууу, пару дней". Окей, работаем.
Аутсорс - фигак-фигак и в прод заказчику. А дальше, случись чего мозговыносящие, две двери - костыли или "ящерицын хвост" + чернильное облако. Иногда, это поделие так и живет годами и все думаю. - "Почему так перестраховывалась?", но чаще, тем парням кто на галере с Вами, надо закладываться под масштабирование, поддержку и качественную конвертацию накопленных данных - им с этим жить, потому и перестраховываются. Истина - посередине +/- эпсилон умноженное на коэффициент выгорания мидлов.
Ждал таких комментариев. Аутсорс плохо, ИИ вообще зло и только вонючие бородатые недооцененные и непонятые никем смузихлебы это тру. Причем, что удивительно, чем больше сеньоров и всяких умных тимлидов (а лучше еще пару продакт овнеров конечно), тем, внезапно, сложнее и больше разработка. А потом еще и выясняется, что, опять внезапно конечно, но все равно: "костыли" + "монолит" + "нету документации". Ну-ну. Ага.
ИИ отлично занял свою нишу помощника в мелких задачах и скетчей для задач среднего уровня и анализа данных, он инструмент. И как бы вы недолюбливали «смузихлебов», «пасти» и пользоваться ИИ будут они, пока менее шапкозакидаательный ПМ пасет их. Остальное, пока - влажные мечты СЕО с мягким мозгом и акционеров ИТ-компаний, которым они их транслируют и которые играют в рынок финансового капитала, им в целом пофиг на средства производства ИТ и они в них не шарят.
Аутсорс -тоже отличный инструмент, к месту. Но шантажировать им коллектив и демпинговать сроки, так себе идея. Если у вас уж совсем нет доверия коллективу, сделайте совместный разбор предыдущих затяжных задач, думаю все станет ясно.
зачем вам свой штат, если аутсорс так хорошо справляется?
Просто @WindMillописал вполне рабочий подход который используют проджект/продакт-менеджеры, у которых нет IT-специфичного опыта но есть общий опыт менеджмента, и которым нужно управлять командой мидл-разработчиков без нормального тимлида. Такое встречается не так и редко, особенно в небольших стартапах. Да, это не очень эффективный подход, но для другого нужны более квалифицированные кадры, которые не всегда есть возможность нанять.
У нас был похожий пример, дан поиск на сайте, пагинация и тд, надо исключить из поиска результаты по такому то критерию.
Аутсорсер вместо того чтобы подумать и исправить запрос к поисковому движку, решил просто через цикл исключить результаты из каждой страницы результатов... То, что некоторые страницы вместо 10 результатов стали выдавать 2-7, а некоторые вообще пустые - пм не заметил и принял работу. Спохватились только когда первая страница стала пустой...
Скупой платит дважды
у нас аутсорсер зафигачил в onclick каждой торговой позиции тело js функции которое через jquery инкриментировало корзину и делало ajax запрос на отдельный php файл.
Толсто, кабан кабаныч, попробуйте потоньше
Программисты хитрые, они не говорят "Мы не знаем, когда сделаем задачу", они говорят "AGILE". Существует два распространенных подхода к оценке задач в условиях неопределенности.
За 20+ лет в профессиональной разработке ни разу не слышал, чтоб кто-то на вопрос о сроках отвечал аджайл, всегда называли конкретные сроки и всегда задачам ставилась дата релиза. Разница лишь в том, что опытные в оценке команды и лиды чаще всего укладываются в назначенные сроки, неопытные в оценке очень часто не укладываются. Но если у неопытной команды опытный менеджер, он накинет время сверху и все будет нормально. :)
Неправильная оценка задач - это когнитивная ошибка (ошибка планирования) и к сожалению ей подвержены все, даже опытные специалисты. Единственный вариант - закладывать сроки, в которые с шансом 80-90% уложишься
Давайте будем честными... Содержание статьи вторично. Пока читал, начал жалеть, что кармы не хватит минусить её. Но имеет смысл простить за блок советов в конце.
Главные навыки - способность быстро учиться новому и эффективно взаимодействовать с командой.
Если чего-то не знаешь - это нормально, спроси.
Если не успеваешь к срокам, о которых договорились, это нормально, главное скажи об этом как можно раньше, и подсвети что не учли при оценке.
А если ты только в поисках первой работы, не пробуй выучить все, иди на собеседование, возможно ты уже знаешь достаточно.
Вот интересно, а где в России используется в банках cobol. Я вот все время с банками работаю уже 15+ лет и cobola нигде ее видел. Есть какой-то продукт может который на cobol?
В России онлайн банкинг начал развиваться относительно недавно, и поэтому сразу на современных языках, COBOL - это скорее про Европу/Америку
В Росси есть свой банковский Cobol - паскаль, точнее уже Delphi. До сих пор зовут и предлагают хорошие деньги. Но не настолько чтобы выпасть и индустрии на несколько лет и потом мучаться вопросом - как найти работу.
В России есть 1С, он всем Паскалям/Дельфям COBOL
"Я вам на скажу за всю Одессу...", но что-то мне кажется что на 1С ядро АБС банка на 50млн клиентов не построить... Там ведь не только счета-проводки, но и еще очень много чего... Да и производительность-надежность там мегакритична.
Или есть примеры реальные? Я просто не в курсе...
Нет. Не дотягивает никак. Для начала он опоздал почти на 10 лет. TurboPascal старше.
Во-вторых 1С это не про нагруженные системы. Это про универсальные системы. Это такой яваскрипт на все случаи жизни. Стильно-молодёжно :-) Но с паскалем это и рядом не стояло.
А вот чистый паскаль - это как раз про высоконагруженные системы с очень малым временем отклика. Сам такое делал, там где 1С подобные системы будут отчёт строить несколько часов, у меня уходило несколько минут, причём большая часть времени - выгрузка сложного по структуре отчёта во много страниц со сложным форматированием в Excel.
А такие вещи, как, например, графическая вёрстка, в 1С вообще нереализуемы простыми способами.
Лучше может быть тот же Паскаль, но со вставками на Си при необходимости ещё бОльшего быстродействия.
Ну и самое главное - при своём хорошем быстродействии Паскаль ещё хорошо себя показал именно в банковских расчётах, за что его в банках и любят. Плюс отсутствие сишных проблем с безопасностью (переполнение буфера и др. атаки).
И вообще обычно это стабильный код, который не падает и работает годами. Поэтому до сих пор ему нет замены в его сфере. Разве CPython и то это лишь намёк.
Ну и самое главное - при своём хорошем быстродействии Паскаль ещё хорошо себя показал именно в банковских расчётах, за что его в банках и любят. Плюс отсутствие сишных проблем с безопасностью (переполнение буфера и др. атаки).
А если к классическому процедурному паскалю добавить нативную поддержку всех типов данных, что есть в БД (дата/время, decimal/numiric) и полную интеграцию с БД (возможность поиска/чтения/записи по индексу, возможность интегрировать SQL выражения непосредственно в код и т.п.), то получите RPG, который я тут уже упоминал.
Ну вот как раз в Delphi это и имеется. И для работы прямой работы с Oracle тоже есть замечательные компоненты.
Не, это совсем не то :-) Я с 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 и много прочих разных. И обратно - из строки или числа в дату/время.
Финансовые вычисления вообще все идут только с числами с фиксированной точкой. Есть, в том числе, операции с округлением...
Вот тут делал небольшой обзор языка в современном его виде.
Там еще со структурами можно очень гибко работать...
Нет. Это совсем не то. Это похоже на FoxPro. Когда то в нём кое-что действительно сделал. Но и всё на этом.
Во-первых всё, что встроено в язык, плохо работает с нормальным сервером БД. Сервер постоянно обновляется, sql постоянно дорабатывается.
ИМХО ни в коем случае нельзя одно перемешивать с другим. Вот типы данных да. Но тут проблем обычно нет.
Запросы только динамические. Всё равно статические без поддержки со стороны ядра СУБД тоже автоматом становятся динамическими.
Во-вторых никакой самодеятельности руками. В коде таких вещей не должно быть в принципе.
Когда у вас сотни таблиц в большой разветвлённой структурой, сотни ГГБ данных, множество операторов и жёсткий realtime - у вас в принципе не будет времени писать такие вещи вручную.
Всё это делается в соответствующих компонентах мышкой, быстро, качественно, надёжно. Вам нужно только подключить запросы на выборку, подключить их к выводу через толковые виузальные компоненты и дальше всё забыть.
Работа должна идти на уровне СУБД, там должны быть вьюшки, там должна быть оптимизация, там должны быть хранимые процедуры и все проверки и там все запросы, написанные вручную или автоматизировано. Приложение должно быть максимально автоматизировано и изолированно, никакой ручной работы.
Во-первых всё, что встроено в язык, плохо работает с нормальным сервером БД. Сервер постоянно обновляется, sql постоянно дорабатывается.
Ну начнем с того, что SQL вообще был придуман не для разработки. Это инструмент больше для аналитика - быстро и без программирования повертеть данные так и этак.
Потом стали натягивать сову на глобус.
Что касается сервера - DB2 является частью ОС. Она туда глубоко интегрирована. Как и движок SQL. И тут нет понятия "сервера" - никаких "подключений к серверу" тут не нужно. SQL запрос можно выполнить системной командой RUNSQLSTM или RUNQRY (для параметризированных запросов).
Аналогично, компилятор языка - это тоже часть ОС. Т.е. там все очень эффективно между собой взаимодействует.
Вот типы данных да. Но тут проблем обычно нет.
Ну как нет... Когда вы читаете с диска блок данных в буфер, а потом вам нужно каждый раз, прежде чем что-то с этими данными делать, преобразовать их к тем типам, с которыми умеет работать язык - это проблема производительности. Даже работая с не сильно большими выборками по паре-тройке сотен тысяч записей.
Запросы только динамические. Всё равно статические без поддержки со стороны ядра СУБД тоже автоматом становятся динамическими.
Вот именно. А когда есть поддержка со стороны БД, все это работает быстрее. По нашим замерам на "динамику" запросов в рантайме может уходить до 30% времени и ресурсов. И когда запрос начинают дергаться десятки и сотни тысяч раз в секунду это становится проблемой.
Во-вторых никакой самодеятельности руками. В коде таких вещей не должно быть в принципе.
О как? А где они должны быть? Мы работаем не с клиентским приложениями. Мы делаем то, что работает на центральных серверах банка.
Когда у вас сотни таблиц в большой разветвлённой структурой, сотни ГГБ данных, множество операторов и жёсткий realtime - у вас в принципе не будет времени писать такие вещи вручную.
Десятки тысяч таблиц, десятки терабайт данных. Из которых 3-5 Тб изменяются ежедневно в миллионах бизнес-операций.
А для жесткого реалтайма существуют специальные операционки. И это точно не про SQL - он не способен обеспечить гарантированное время отклика в любых условиях (основное требования реалтайма). Прямая работа с БД сложнее с точки зрения написания кода, но в целом более эффективна по использованию ресурсов и предсказуема по времени выполнения. Я уже приводил пример задачи где SQL решение работает 7-8 часов, а решение с прямым доступом к БД тоже самое делает за 20-30 минут.
А - понятно, не сразу сообразил что это DB2. Всегда была немного интересна, но руки так и не дошли.
Насчёт серверов понятно, я обычно делал тонкого клиента и всё крутилось в СУБД. Это очень удобно и производительно. Так что всю работу всегда перекладывал на сервер, на клиенте только отображение и какая-то специфика.
Ну мы пишем то, что на серверах крутится. Это похоже на то, что иногда называют "модульным монолитом". Конечно, не монолит ни разу. Скорее - модель акторов. Большое количество модулей, каждый из которых реализует некоторую логическую функцию и имеет жестко заданный контракт (ABI).
То, что работает на клиентах вообще никакого достпа к БД не имеют. Сервера изолированы от внешнего мира. Все общение с ними или асинхронно через очереди (IBM MQ + Kafka) или синхронно через вебсервисы на ESB шине. В этом случае для клиента (скажем, мобильное приложение) есть REST API которое дергает WS, а на стороне сервера каждому WS есть свой сервис-модуль который выполняет всю работу и при необходимости возвращает наверх resulset. Например:
exec sql set result sets with return to client
array :ArrayPbcRSet for :iPbcCount rows;где ArrayPbcRSet массив предварительно заполненных таких вот структур
// ResultSet для результатов проверок
Dcl-DS tDSPbcRSet Qualified template;
$$IDP Char(3);
$$IDR Char(7);
$$NMS Char(70);
$$CHK Char(1);
$$ATR Char(2000);
End-DS;возвращаемый в виде SQL выборки.
WS при этом фактически является тонкой прослойкой для согласования типов данных используемых на сервере и потребителе.
Но наша задача только то, что крутится на сервере. Т.е. сервис-модули. Остальное уже другие команды делают.
А вообще сервера своей жизнью живут - там постоянно что-то крутится (и очень интенсивно). Общение с внешним миром это только небольшая часть работы. Какие-то модели запускаются по расписанию, какие-то по событиям различным, какие-то откуда-то вызываются...
Поскольку каждый модуль реализует некую бизнес-логику, он может быть изменен независимо от других (при условии сохранения контракта). Оптимизация или бизнес-логика поменялась...
Я по линии автоматизации комплаенса работаю. В том числе со списками росфина (террористы и прочие бармалеи). Какое-то время назад росфин поменял формат этих списков (которые нам регулярно приходят). Мы поменяли процесс загрузки и формат БД где все это хранится. Но с этим связана куча всяких проверок, стоплистов и прочего. Сейчас вот переделываем все старые модули с тем, чтобы они работали уже не по старой базе, а по новой... Но так, чтобы для потребителей этих модулей (а их очень много) ничего не поменялось...
Бывает оптимизация когда модуль полностью переписывается чтобы ресурсов меньше потреблял, работал быстрее. И опять, пока контракт сохраняется - для потребителей это незаметно.
Что касается SQL, то используем его ограничено - для объемных выборок по нескольким таблицам с большим количеством условий. Только на чтение и то при условии что плотность вызовов модуля невелика - при большой плотности вызовов из разных заданий SQL может работать не очень эффективно.
Да и многие вещи на RPG работают быстрее и реализуются проще. Операции типа проверить наличие записи для заданного значений ключа вообще не требуют обращения собственно к таблице (чтения записи). Только проверка индекса. На RPG все это управляемо.
Или минимальное-максимальное значения индексируемого поля. В RPG это тоже делается одной операцией - спозиционроваться на первую-последнюю запись в access path что и быстрее и по ресурсам эффективнее чем тоже самое делать через SQL.
В общем, тут комплексный подход, для каждого случая используются свои методы на основе опыта и многочисленных тестирований производительности через PEX (Performance EXplorer - есть тут такой инструмент).
Понятно, я делал монолит средствами СУБД, получалось неплохо :-)
Интересная у вас специфика, но мне нравилось всё это реализовывать средствами СУБД, чтобы клиенты только посылали основные запросы и получали готовый ответ. А всё остальное, в том числе и задачи по расписанию работали на сервере и жили своей жизнью.
Ну у нас так и есть. Все внешние системы (а их более 60-ти) работают по запросам (очереди, WS) и к БД вообще никакого доступа не имеют.
Другое дело, что "средствами БД" все это не реализовать - это hiload система - более 100млн бизнес-операций в сутки, более 50млн клиентов (а каждый клиент это огромное количество связанных данных). Т.е. нагрузка очень высокая и очень высокие требования к производительности и потреблению ресурсов.
Да и реализовать всю бизнес-логику только средствами БД нереально. Она бывает достаточно сложной.
Часть объемы информации бывают такими, что для обработки их в разумные сроки необходимо распараллеливание - есть головное задание, которое занимается отбором информации и формированием пакетов для обработки, есть конвейер, куда головное задание выкладывает пакеты и есть несколько заданий-обработчиков, которые берут пакеты с конвейера и обрабатывают. Только средствами БД такое не реализовать.
И при всем этом на сервере одновременно крутится огромное количество процессов с самой разной логикой. Бан это же не только счета-проводки, там еще много чего всякого.
Можно, не поверите, но можно :-)
Функционал у того же SQL Server-a просто гигантский, влючая типовые решения для обработки данных о отчётов ()правда я всегда делал сам).
А вы знали что он видит файловую систему и может обрабатывать файлы без особых проблем, к примеру. А что его функционал без проблем расширяется при помощи C#? А InMemory обработка? И это я про старый функционал говорю.
Oracle тоже не на месте сидит, хоть и остаёт.
И т.д. И т.п. На само деле мало кто использует современные СУБД по полной программе. Обычно прокладка и всё. Особенно web решения. Они вообще почти ничего не знают о настоящем sql. И вместо этого тянут данные к себе и устраивают обработку данных за пределами СУБД, чтобы не зависеть от конкретного решения. Выглядит грустно.
Ну вы же понимаете что у нас тоже самое, но со стороны языка. Вполне полноценный язык. Оптимизирующий компилятор. Поддержка всех типов данных БД. Возможность NoSQL работы с БД (которая во многих случаях и быстрее и эффективнее по ресурсам чем SQL) средствами языка. Возможность расширения за счет использования С/С++ (можно собрать программу из двух исходников один из которых будет на RPG, второй на С/С++ или из RPG кода вызывать любу. функцию из библиотеки С). Плюс возможность встраивать SQL запросы в RPG код.
И обратно - можно написать программу на RPG и подключить ее в SQL как хранимую процедуру, UDF/UDTF.
Есть у нас такая штука как очереди данных. Не монстры типа Kafka или IBM MQ а быстрые и простые очереди. Ну что-то типа mailslot в винде, только помощнее. Удобны для организации всяких конвейеров, межпроцессного взаимодействия и т.п.
Сделал API для работы User Queue. На С (такие вещи удобнее на С писать). Прописал к ним RPG интерфейсы. Сделал на RPG набор SQL процедур. Сделал набор команд системных. И все. Используй как удобнее. Хоть из С/С++, хоть из RPG, хоть из SQL. Полная интеграция всего со всем.
Особенность RPG в том, что любая написанная на нем программа может использоваться как процедура в другой RPG программе. Просто она описывается как extpgm (в отличии от процедуры, скажем, в другим модуле или динамической библиотеке, которая описывается как extproc). Так называемое "позднее связывание".
Для меня delphi\pascal вообще палочка выручалочка. Я хорошо знаю SQL и в общем уже много сложных приложений с бизнес логикой в БД сделал. Мне не нравится тащить логику на клиента, ну может только по минимуму. Поэтому интерфейсы быстро создаю сам в DELPHI. Использовать WEB в моей области разработки для производства и тестирования железа избыточно, сложно и долго. И главное , все десктопные приложения получаются стабильные и неприхотливые к требуемой памяти без каких либо внешних зависимостей.
Аналогично, я практически всю работу по сложным выборкам отдаю на хранимки, если ещё и поработать с оптимизацией то работает замечательно.
Но десктоп почти умер, а в С++ нет ничего подобного :-( Вот и мучаюсь.
Не умер десктоп, просто мобильных приложений и сайтов-сервисов стало больше. Кол-во софта на ПК не уменьшилось и стабильно пишется новый. Посмотри на себя и на других: если существует клиент какого-то сервиса (мобильный или десктоп), то именно его предпочтут обычному сайту.
На производственных терминалах тоже будет десктоп софт, а не браузер и т.д. Просто потому что работает это всё стабильнее и быстрее, чем в браузере, не говоря уже о ряде других преимуществ.
Ну вот я делал достаточно сложную систему управления для предприятия. Перешли на веб и оно умерло. И таких примеров масса.
А ещё молодёжь не понимает зачем нужны компьютеры, мы скоро останемся с ПК как когда-то наши прадеды с логарифмическими линейками. Можно всё посчитать, но все пользуются простейшими калькуляторами и даже без логарифмов.
Это не значит, что если бы сделал ещё и нативный десктоп клиент, то им бы не захотели пользоваться.
Веб удобен разработчику, но не пользователям.
Веб удобен там, где не особо удобно ставить приложения и держать их постоянно актуальными при регулярных изменениях.
Для разработчиков он совсем не обязательно удобнее. Ну то есть лично я пишу и веб и десктоп, в зависимости от хотелок клиентов. Десктоп писать гораздо проще. Особенно если мы говорим о сложных приложениях.
Так нативный и был. Но перешли на веб и всё умерло.
Вот только проблема совсем не обязательно в вебе как таковом...
Вот именно в нём на все 100, как только издание переползло с бумаги в инет - всё радикально изменилось.
Веб его тоже можно сделать хорошо и удобно, а можно плохо и неудобно.
Те же Schäffler, Siemens и Bosch вполне себе используют веб в куче мест. В том числе и на производстве. И это отлично работает.
Можно, но это просто всё совершенно иное.
Я слабо могу себе представить что такого не может современный веб. Ну если сравнивать его с десктопом. Особенно с тем десктопом, который на этом вашем предприятии был реализован в прошлом.
Я про это нигде и никак не писал.
Но можно и об этом.
Надёжность кода. В принципе рядом не стояло ничего и браузерного, а зачастую и из серверной части приложений.
Безопасность, современный веб это сыр с кучей проблем по безопасности.
Быстродействие. Тут ни один браузер рядом с десктопом не стоял.
Доступ к ресурсам машины. То что в декстопе норма, то для браузера признак блокировки антивирусом :-)
Ну и весь современный десктоп интерфейс плохо работает с UI в браузере, по мелочам, но они страшно раздражают, если вы целый день в этом сидите. Нативный интерфейс от операционки на порядок стабильнее и просто удобнее.
В общем тот десктоп из прошлого просто с ноги выносит практически любое приложение из веб, даже на web-assembly. Но проигрывает в универсальности, особенно проблемы с телефонами.
Вы конечно извините, но по тому что вы написали складывается впечатление что вы не особо "умеете" готовить тот самый современный веб. Ну или как минимум писать на нём аналоги десктопных приложений.
И тогда и не удивительно что никто не хочет пользоваться результатом.
что вы не особо "умеете" готовить тот самый современный веб.
Тогда этого никто не умеет. Открыть толстый (в смысле количества строчек) excel (ну или csv) файл в браузерной версии приложения или десктопной - разница по скорости работы ну очень большая.
Может, Microsoft в данном случае халтурила и посадила писать Web приложение тех, кто не умеет. Но что-то не верится.
Мне интересно каким образом это должно доказывать что "никто не умеет"? Ну то есть с чисто логической точки зрения это доказывает максимум что кто-то ещё отдельно взятый не умеет.
А может просто и не ставит себе как цель поддерживать хорошую скорость работы на больших файлах.
Мне интересно каким образом это должно доказывать что "никто не умеет"?
Тем, что если Microsoft не посадила писать тех то умеет на свое флагманское приложение - то это означает, что таких вообще исчезающе мало. Ну или они настолько дорогие, что не захотела.
Ну так "исчезающе мало" это уже не "никто не умеет".
Кроме того, как я уже написал выше, лично я не уверен что Microsoft вообще ставил себе целью иметь хорошую производительность с большими файлами в этой самой веб-версии.
Microsoft вообще ставил себе целью иметь хорошую производительность
Так вот именно. Это надо отдельно ставить цель. А в десктопе вот прямо сейчас накидал, ничего не понимая в построении UI на питоне.
import tkinter as tk
from tkinter import ttk
root = tk.Tk()
root.geometry("400x300")
treeview = ttk.Treeview(columns=("i", "text"))
for i in range(1000000):
treeview.insert("", tk.END, text = str(i), values=(f"Element {i}",))
scrollbar = ttk.Scrollbar(orient=tk.VERTICAL, command=treeview.yview)
treeview.config(yscrollcommand=scrollbar.set)
scrollbar.place(x=0, y=0, height=180)
treeview.pack()
root.mainloop()Список в две колонки на миллион позиций. Не тормозит. Занимаемая память - ~500Mb. Много, конечно, но как раз случай 'задача и не ставилась'.
Вебовский эквивалент, pls?
Так вот именно. Это надо отдельно ставить цель
Конечно надо. В том числе и на десктопе.
Список в две колонки на миллион позиций. Не тормозит
Просто список и для веб-версии не то чтобы огромная проблема.
И, как я уже писал выше, десктоп разработчику писать действительно проще. И да, в том числе и в контексте производительности. Но это не значит что невозможно писать нормальные приложения и в вебе.
Невозможно, ограничения платформы в виде браузера и интерпретируемых языков. ИМХО сама технология мертворожденная, но всех устраивает, так что будет жить и развиваться.
Вы никогда ничего не слышали про WebAssembly или там банально тот же Blazor?
Я его сверху упомянул ;-)
Тогда зачем писать про "ограничения в виде интерпретируемых языков" ?
Потому что всё равно до нативного приложения это не дотягивает.
В чём конкретно? И точно есть требования чтобы дотягивало?
Есть, когда идёт обработка объёмных данных в realtime весь веб идёт лесом, густым и тёмным.
А зачем такую обработку данных делать в приложении и уж тем более в браузере? Почему её нельзя делать в бэкэнде или каком-то отдельном сервисе?
Можно, но по ряду причин это будет страшно с точки зрения разработки. На порядок больше затрат по ресурсам, а на выходе тот же результат. И обосновать такие затраты будет очень непросто. Одно дело когда доработка кода занимает месяц, потому что можно всё быстро отладить на ходу, а совсем другое - когда нужно создавать бэкэнд и уже отлаживать его. Ну или сервис.
А так да, всё что можно было вынести на уровень С УБД, было вынесено и жрало ресурсы только сервера. Но были вещи, которые на уровне sql реализовывать было нелогично, например работа с графикой в realtime.
На порядок больше затрат по ресурсам, а на выходе тот же результат
Это ещё почему? Почему сервис/бэкенд у вас потребляют вот прямо на порядок больше ресурсов?
Одно дело когда доработка кода занимает месяц, потому что можно всё быстро отладить на ходу, а совсем другое - когда нужно создавать бэкэнд и уже отлаживать его. Ну или сервис
У вас веб вообще без бэкенда/сервисов работает?
У вас в десктопном приложении обработка этих самых "объёмных данных" происходит прямо в UI и не выделено куда-то в отдельный модуль/сервис/класс?
Но были вещи, которые на уровне sql реализовывать было нелогично, например работа с графикой в realtime.
Какое отношение графика имеет к обработке данных? По идее графика должна показывать уже обработанные данные.
И у вас реально нет никакого слоя бизнес-логики между базой данных и UI?
Почему сервис/бэкенд у вас потребляют вот прямо на порядок больше ресурсов?
Потому что нужна быстрая отладка. Без UI приложения это всё ну очень сильно затягивается.
У вас веб вообще без бэкенда/сервисов работает?
Да мне без разницы, я им не занимаюсь в данном случае.
У вас в десктопном приложении обработка этих самых "объёмных данных"
Да - обработка объёмных данных идёт в приложении, потому что такая логика работы и это всем удобно.
Какое отношение графика имеет к обработке данных? По идее графика должна показывать уже обработанные данные.
Данные графические.
И у вас реально нет никакого слоя бизнес-логики между базой данных и UI?
Совершенно верно. Вся логика в базе. Быстро, надёжно, качественно. Приложение фактически тонкий клиент (и я подумывал о веб, хотя внутри организации это совершенно не имело смысла), но - есть ряд тяжёлых функций, кстати в том числе и прямой рендеринг шрифтов с заданными параметрами в абсолютных единицах, и я не пробовал, но ИМХО с веб были бы проблемы, хотя, скорее всего, решаемые. Плюс интерфейс обрабатывает много данных и хочет банально быть быстрым. Никаких там секунду на обновление страницы, что, как показывает практика, нереализуемо, банально много данных, фильтры, сортировки, выделения, плюс всякий мелкий функционал обработки в realtime.
Извините, но у вас реально какой-то странный подход и странная архитектура.
И даже если это как-то работало с десктопом, то тащить эту архитектуру в веб это абсолютный бред.
То есть если у вас там кто-то по каким-то причинам решил перейти на веб, то над архитектурой приложения стоило хотя бы немного подумать. А не пытаться тащить это всё один в один в веб. И это как раз таки однозначно то самое "не уметь готовить"....
У меня эффективный подход и хорошая архитектура. что обеспечивало быстрый и качественный результат за короткие сроки. Одним словом это не разработка ради разработки, а разработка ради результата, и я не сказал бы что совсем уж особенная. Такие тонкие клиенты существовали до прихода веб и регулярно встречались Хотя в общем тот же SQLServer позволяет создать вполне себе адекватного тонкого клиента для веб без участия кого-то ещё, но я не пробовал.
В данном случае я не только умею готовить, но и обхожу в этом многих других, если не всех ;-) Пока я даже близко не встречал никого, кто мог бы решить эту же задачу в те же сроки, с тем же функционалом и с тем же качеством и стабильностью работы.
Помню много лет спустя я делал ещё одно приложение под декстоп, которое потом команда переводила на веб. Неплохая команда, год переводила по готовым исходникам то, что я написал по вечерам за полгода в одиночку. И не смогла без ошибок, потом ещё дорабатывала, правда гордость им не позволяла спрашивать как и что должно работать по шагам :-) Это конечно не показатель, но грамотно выбранная архитектура на десктопе позволяет разрабатывать надёжный и качественный продукт за короткие сроки почти с любым функционалом.
У меня эффективный подход и хорошая архитектура. что обеспечивало быстрый и качественный результат за короткие сроки.
Но при этом пользоваться никто не захотел. Но виноват в этом конечно именно веб...
Все радостно пользовались и были довольны. Пока не пришёл веб и почти похоронил предприятие.
Что значит "пришёл веб"? Он сам из ниоткуда пришёл?
Кто-то заставлял его использовать у вас на предприятии?
Да, сам, да снаружи. Внутри предприятия не нужен, это правда. Но раз он стал торчать наружу и поменял вообще все правила работы, то и внутреннюю часть тоже сделали на веб. Я ж писал - всё стало иначе.
Но раз он стал торчать наружу и поменял вообще все правила работы
У вас предприятие подстраивают под приложение или наоборот приложения под нужды предприятия?
то и внутреннюю часть тоже сделали на веб.
Кто-то же принял решение так сделать? Кто? Почему? Зачем?
Почему вы решили что проблема не в конкретной реализации, а в вебе как таковом?
Приложение под предприятие. Поэтому десктоп и умер.
Сильно изменилась и на два порядка упростилась вся логика(offline товар был заметно сложнее по структуре, чем online), плюс уже был создан веб для клиентов и заказчиков, так что логично что и внутренняя часть была сделана аналогично.
Без веба в обществе - среди заказчиков и клиентов, предприятие было бы глубоко offline до сих пор и продолжало бы зарабатывать деньги. Кстати в России филиалы этого весьма известного предприятия сохранились до сих пор уже в вебе, но в России с этим проще, а у нас видимо не хватило оборота, стоимость для клиентов в вебе очень мала, это не позволяет содержать адекватный коллектив, а конкурентов создать очень легко и незатратно. Но это обсуждать не виду смысла, я не знаю детально что там у руководства творилось когда это всё начало сыпаться.
Приложение под предприятие. Поэтому десктоп и умер.
Всё ещё не понимаю как из одного следует другое.
плюс уже был создан веб для клиентов и заказчиков, так что логично что и внутренняя часть была сделана аналогично.
Если всё так логично, то в чём тогда была проблема?
Без веба в обществе - среди заказчиков и клиентов, предприятие было бы глубоко offline до сих пор и продолжало бы зарабатывать деньги
Если дело исключительно в этом, то зачем переходили на веб?
И кто сказал что дело было именно в этом, а не в том что просто веб сделали криво?
а конкурентов создать очень легко и незатратно.
То есть существуют конкуренты на вебе и ими таки пользуются?
Ну предприятию пришлось выйти в инет, перевели для клиентов всё на веб и десктоп умер.
то в чём тогда была проблема?
Ну в том что пришлось перейти на это логично, но веб уже не приносил столько денег и всё померло. Но вообще это не проблема, просто эволюция. И так было понятно что так и будет скорее всего.
то зачем переходили на веб?
А вот вы по-прежнему через email запрашиваете данные из библиотеки (к примеру), или скачиваете книгу при необходимости? Вот тут аналогично.
просто веб сделали криво?
Я им не пользовался, но ИМХО нормально был сделан для того времени, не хуже и не лучше.
То есть существуют конкуренты на вебе и ими таки пользуются?
Конечно, до этого в offline конкурентов, сильных, не было в принципе, было полное и абсолютное доминирование на рынке много лет. Вообще очень известное предприятие среди множества обычных людей. И оно развивалось, создавались новые направления, правда уже не столько успешные, но работало. А потом пришёл инет и конкурента можно было создать на два порядка быстрее и проще, даже не имея опыта и подобранного многолетней работой коллектива, пусть не такого успешного, зато очень дешёвого и клиенты разбрелись. А великий уравнитель в виде гугла выровнял предприятие и его конкурентов в выдаче (я не проверял, но если они не дураки, то это легко делается).
Вы конечно извините, но складывается впечатление что вы не умеете писать то самый десктоп, если вас устраивает современный веб. Поэтому неудивительно, если вас это может устраивать, но этим современным вебом никто не хочет пользоваться.
Во первых конкретно в вашем случае мы сравниваем современный веб с легаси десктопом.
Во вторых я лично тоже предпочитаю писать и использовать десктоп. Но если клиенту нужен веб, то он получит веб.
И в третьих "никто не хочет пользоваться" это однозначно неправда. Потому что многие вполне себе пользуются и довольны.
И легаси десктоп выигрывает по всем пунктам без особых усилий.
А в остальном я полностью с вами согласен :-)
Вот прямо по всем? Ну расскажите мне тогда как там у вашего легаси-десктопа например обстоят дела с кроссплатформеностью.
Никак, вообще никак :-)
Но она и не требовалась на то момент.
На какой "на тот"? И с чего вы решили что она например не потребуется в будущем?
И кто у вас там вообще определяет требования и каким образом?
На момент написания. И это был внутренний продукт, наружу никак не торчал. Ну и прикрутить веб к нему в принципе можно было, но смысла не было вообще.
Ну я определяю требования, надеюсь вас это никак не задевает? А то так и до личностей можно дойти.
Если вы их определяете и веб под них не подходят, то зачем вы делали веб?
А я и не делал, просто так сложилось, что произошёл переход в веб. На самом деле надо было раньше, но offline организации приносил гораздо больше денег.
Я уже совсем запутался. Что значит "так сложилось"? Кто-то же решил что это надо делать? Кто? Почему?
Что значит "надо было раньше"? Это самое "надо" как раз таки подразумевает что были какие-то требования из-за которых собственно и было надо. Какие? Откуда они взялись?
Раньше оно приносило деньги в offline, но offline умер, общество перешло на online, пришлось организации перейти на online. А там стало тяжко из-за конкуренции, в общем организация почти умерла.
Какое "общество"? Речь же шла о системе управления предприятием?
Общество, которое деньги приносило предприятию. Наше общество :-)
А какое отношение "наше общество" имеет к системе управления предприятием? У вас что любой человек может вашим предприятием управлять?
Кто вам за разработку платит? Кто требования ставит? Кто результат принимает?
Общество перестало искать информацию offline и стало получать информацию online. На этом всё и закончилось.
Кто вам за разработку платит? Кто требования ставит? Кто результат принимает?
У вас слишком много странных вопросов. Требования пользователи ставят, им надо чтобы работало так как им надо, они же и принимают. Точнее я сам ставлю требования и принимаю. Так оно гораздо лучше работает, потому что пользователи не всегда способны точно описать что им надо. Главное чтобы им было удобно и они были довольны.
Общество перестало искать информацию offline и стало получать информацию online. На этом всё и закончилось.
А причём здесь какая-то система управления предприятием? Каким образом это должно мешать и дальше использовать десктоп-приложения?
Требования пользователи ставят, им надо чтобы работало так как им надо, они же и принимают.
Ну так за "систему управления предприятием" обычно кто-то конкретный платит. И он же требования озвучивает.
Точнее я сам ставлю требования и принимаю
То есть вы по своим собственным требованиям написали "веб-приложение для системы управления предприятием". Сами же у себя его приняли. А потом каким-то пользователям оно не понравилось? Я всё правильно понял?
Декстоп нужен был для самого предприятия, для его работы. Но веб изменил формат работы, формат представления информации, всё стало сильно проще. Да - можно было десктоп переделать под новые задачи, но решили что тот кто уже сделал веб, тот же естественно и внутреннюю часть сделает.
И он же требования озвучивает.
Да, но тут всё было сложнее, фактически этим занимался весь коллектив, такого рода коллективный заказчик, мне нравилось, в том плане что я реагировал на каждого лично и подстраивал всю систему так, чтобы всё работало и даже самые сложные и с виду ненормальные пожелания, согласованные с руководством тут же на месте, реализовывались.
написали "веб-приложение для системы управления предприятием".
Нет - это уже без меня.
написали "веб-приложение для системы управления предприятием".
А их всех уволили, так что вряд ли им сильно понравилось пришествие инета.
Да, но ведь переход на веб был не просто чтоб было, а по конкретным причинам. А десктоп скорее всего, даже если и работал, то его перестали поддерживать. Все, конечно, догадки, но если бы десктоп клиент был актуальным и имел нормальную систему обновления, то большинство бы предпочли именно его.
Другими словами, если бы вы сейчас создали удобный и быстрый клиент на десктоп, а веб бы перестали обновлять, то все бы перешли на него. Но ведь это не значит, что "веб умер", верно?
SAP
Насколько знаю - нет. В РФ как минимум 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 куда-то еще в том, что это специализированные языки. Они содержат в себе много вещей, которые в других языках так просто не реализовать - потребуются внешние библиотеки/фреймворки, код будет сложнее, скорее всего будет просадка в производительности что потребует наращивания мощностей железа (а банковские серверы это не то, что можно в любом магазине купить, там и мощность нужна и, главное, надежность - все это стоит очень ощутимых денег).
Т.е. любой такой переход - очень долго и очень дорого. И, главное, вложения не отобьются, не принесут какой-то дополнительной прибыли. Все будет работать точно также, только потратите денег и времени.
И тут не надо ориентироваться на "нерелевантный опыт" - если вас это волнует, ищите работу где-то в другом месте. Банк живет по своим законам и метрики там тоже свои. Это отдельная, достаточно замкнутая область. Как и, к примеру, промавтоматизация.
planing => planning
Сама по себе точность оценки сроков как-то влияет на качество или скорость выполнения задачи? Это же просто формальность, необходимая для создания иллюзии контроля над процессом. Попытка натянуть методы, применяемые в промышленном производстве, на абсолютно иной вид деятельности.
Mожно подумать что программирование ограничивается одним WEB и джавой. Существует множество средних и мелких компаний, у которых внутренних задач столько что их делать и не переделать так как основной элемент у них - электронные таблицы . Web и джава там нужны как козе баян в задачах производства и сервиса своей продукции, к примеру. Программисты там нужны и на микроконтроллеры и на сопуствующее ПО сервиса и производства приборов к примеру. Зарплаты там неплохие, но меньше чем в компаниях которые занимаю WEB на продажу и не такая потогонная система . Зато можно получить опыт как программиста и не ловить журавля в небе. А уж потос решать, нужно ли тебе рвать жилы в WEB компании или все-таки работать ради жизни а не жить ради работы.
Да, все верно. Уже написал выше - ровно тоже самое относится и к банкам (если говорить о том, что работает на центральных серверах). Там все очень консервативно, просто так, рефакторингом ради рефакторинга никто никогда не занимается. Свой мир - свои правила. Туда не приходят на год-два. Чтобы чего-то достичь нужно там проработать несколько лет пока во все тонкости конкретной системы вникнешь. Но и платят прилично за это. Потому текучка очень низкая.
Берем самую простую задачу которая есть на проекте и говорим - она занимает один стори-поинт.
Автор концепции стори-поинтов вкладывал иной смысл 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, но сути это не меняет.
"Канбан" Тойоты и "Канбан-метод" - разные штуки. Там это были карточки на ящиках с деталями
Сейчас от разработчика ждут не только написание кода, но и работу с ci/cd, тестирование, поддержка сервиса в проде, эффективную коммуникацию с командой, а иногда и с бизнесом
Это, как и разговоры о специалистах с любой буквы, вроде T - (как всегда) желание бизнеса сэкономить.
Понимать устройство и принципы работы смежных инструментов - один разговор, бегать от кода к пайплайну через тестирование после созвона с продукт овнером - другой. Если у конторы нет денег на девопсов и тестировщиков - нужно менять контору
Зависит от размеров проекта. Чем меньше - тем больше ролей и это естественно.
Моя основная специализация - бэкендер. На одних проектах могу только бэк писать, а могу брать роль тимлида, QA, PM, поддержки и аналитика. На самом деле, слов много, а суть одна: маленький проект и ты на нём делаешь всё. При том смежное ты делаешь совсем не в том объёме, как делают когда нужные отдельные люди на роль. Ну типа тимлид в команде из 3-х человек и 30-ти - это совсем разные навыки.
А ещё я не могу работать "жиродробителем". Если мы моя работа была бы только "вот карточки, там всё понятно что делать, делай их до пенсии", я бы долго не выдержал.
"Да правильно все говорит" (с)
Хоть как-то оценить время на выполнение можно только для рутинных задач. Для всех остальных "сначала надо изучить вопрос, зайдите завтра... или через неделю"
И насчет "невозможно знать всё" тоже правда. Хуже того. Например, "плывет" терминология. Причем и во времени и в пространстве :)
Подберите такую задачу, что N стори-поинтов на ее выполнение занимали ровно 1 час и возьмите за основу не 1 стори-поинтов, а N
Замените N стори-поинтов на 1 час
Прекратите выпендриваться
Без какого языка нельзя представить современный мир?
Внезапный ответ: самый важный язык — это COBOL, созданный в 1959 году.
Да это же байка из США. В других странах всё гораздо моложе в банковской сфере и кобола там скорей всего практически нет.
ПыСы чатгопота со мной согласен
Это скорее миф, что COBOL "повсеместно" используется. Сегодня его применение ограничено определёнными доменами (например, банкинг и госструктуры), где существуют устаревшие, но критически важные системы. При этом новых разработок на COBOL практически нет. Вместо этого современные языки, такие как Java, Python и другие, используются для создания новых систем, а COBOL-системы постепенно интегрируются или заменяются
Позитивный подход: "Я - дилетант, мои коллеги - дилетанты, поэтому команде надо больше общаться, чтобы, как анонимным алкоголикам, не впасть в депрессию не выгореть за пару месяцев"
ведь все это время использовал совсем другие инструменты: вместо Kafka — RabbitMQ, вместо Postgres — MongoDB, а вместо Kubernetes — OpenShift.
А кто-нибудь пробовал не переизобретать каждый раз один и тот же велосипед, а просто освоить уже имеющийся и эффективно им пользоваться?
один велосипед, для ВСЕХ условий????
И какие именно условия изменились?
от проекта к проекту??? Да полно, даже перечислять лень
Ну, например, какие именно условия изменились, что больше НЕВОЗМОЖНО использовать Postgres ?
Не "не хочется", не "я учился на другое", не "за новое мне больше заплатят", а именно НЕВОЗМОЖНО.
откуда вы достали слово "НЕВОЗМОЖНО" ?? Речь о том что одна единственноая субд не может подходить для ВСЕХ условий. Где-то лучше взять монгу, где-то oracle, а где-то вообще snowflake. И будет ошибкой зная и умея только в PG пихать его везде, только по причине того что его знаешь
Речь о том что одна единственноая субд не может подходить для ВСЕХ условий.
Откуда Вы достали слово "одна единственная"?
И будет ошибкой зная и умея только в PG пихать его везде, только по причине того что его знаешь
А мне вот очень нравятся рассказы о том, что какое-то решение оказалось в проекте именно потому, что действующий разработчик это умел.
А тот который его сменил, переписал на то что умел он.
И всё это в рамках одной и той же задачи, без мифического "Где-то лучше взять монгу, где-то oracle, а где-то вообще snowflake."
А вот для MS SQL я прям запросто скажу, что изменилось.
Ну и насколько я помню историю "того, кто уволился из вашей команды год назад. Но даже он успел многое забыть, ведь все это время использовал совсем другие инструменты"
И он использовал не постгрес например потому, что в той компании, где он год отдыхал он не чифтек офисер был, а рядовой разраб, и инструменты не выбирал.
Есть ещё один способ правильно оценить сроки - работает на ура. Дать сутки на то чтобы вникнуть в суть проблемы, разобраться с требованием и прикинуть, как решать задачу. Понятно, что если кто-то пытается за 15 минуть оценить задачу хоть в поинтах, хоть в попугаях, то это всё равно что ткнуть пальцем в небо.
Что касается T-shape, то есть вещи которые обязан знать любой разработчик. Для Java это будет Java, maven/gradle, Spring. Также все бэкэнд разработчики должны хорошо разбираться в сетях, linux, реляционных БД.
Те кто имеет пробелы в базовых вещах - пусть доучиваются
Многие системы на COBOL работают десятилетиями.
Те, кто создавал систему, давно ушли из компании (или из программирования).
(или из жизни)
НА мой взгляд там нет каких-то критических проблем. Да, разработчиков на COBOL мало. Но их много и не нужно. Это узкоспециализированный, нишевый язык. Сообщество по нему есть, курсы по нему есть. Платят за него вполне нормально. Так что там есть достаточное количество разработчиков.
Ну и в РФ он практически не используется. Так что и разработчики на нем тут не требуются.
Аналогично - IBM i/RPG - в РФ минимум 4 банка на этой платформе. Плюс есть вендоры - BTC, Cinimex, RMS-Lab (может еще кто-то). Тоже в это все умеют. Да, ниша. Да, мало. Но какой-то критической нехватки кадров нет. Немного, но хватает для решения задач.
Привет автору.
Есть несколько мыслей по поводу статьи.
Мысль 1: Хоть я и не являюсь действующим программистом, а только заканчиваю учится на программиста всё же я пришёл к тому же мнению что описано у тебя в статье.
Мысль 2: Для написания Дипломной Работы дано 2 + 1 месяца работы, то есть 2 месяца на разработку и месяц на доработку. Так как я начинаю только писать вообще что-то то я решил не париться по причине того как я буду писать свой проект, для меня главное чтобы большее из того что я задумал просто работало.
Ну и на последок не совсем мысль а больше вопрос. Как научиться учиться в IT. Суть в том что тупо спрашивать на форумах это непонятно так как ответы есть но и пробелы в коде-знаниях тоже ни куда не деваются. Отсюда вопрос откуда черпать информацию если нужно за условные 5 дней узнать что-то и это же самое реализовать. Например в моем случае это Rest API на PHP с доступом к нему из браузера по возможности не используя react, laravel и Node.js
Теперь совершается магия - например 95% задач проходят этот путь за 10 дней. Теперь мы можем говорить бизнесу что задачу, с вероятностью 95% будет готова через 10 дней.
Это из физики (теории погрешностей измерений) подход. За ним стоит очень сильная математика из теории вероятности: распределения случайных величин и пр.
Вот узнать как математика работает в данном случае, было бы интересно. Т.к. в этом случае d(a+b) <> d(a)+d(b).
Еще до того, как программирование "стало командным", уже никто не умел ни нормально ставить сроки, ни вмещать всю сложную технологию в одну голову. Эта статья очень вялая попытка снять понятный и здоровый комплекс некомпетентности, без которого не возможен рост над собой, у людей, которые забыли, почему программировать это интересно. Дешевая популярность у отсталых мидлов обеспечена.
Программисты ничего не знают (и это нормально)