Senior Scala Programmer
  • Пандемия коронавируса SARS-CoV-2

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

    Но тут есть и плохая новость. Самые важные цифры это вот эти:

    13.8% в тяжелой и 4.7% — критической

    Это число (особенно 4.7%) падает до 1-2% летальности и ниже только при условии, что людям вовремя оказали медицинскую помощь. Так как с большой вероятностью возникает двусторонняя пневмония и люди нуждаются в ICU (intensive care unit) для поддержания кислорода в крови — иначе могут задохнуться. Так вот я слушал тут одного хорошего врача из Англии и он сказал, что нет шансов обеспечить эти ICU для условно 10% тяжело больных, если заразившихся будет 30-60% от популяции. Просто нет такой возможности. Именно поэтому смертность внутри Ухани сейчас выше, чем за её пределами. Но это лишь до тех пор, пока здравоохранение в других местах не будет перегружено также, как сейчас в Ухани. И поэтому летальность будет сильно разная в разных странах (в зависимости от плотности заселения, уровня здравоохранение и т.д). У Испанки было от 0.1% до 21% смертности по разным странам (от всего населения). И что будет в конечном счёте в стране Х можно только гадать.

    Поддержали: anonymous, Bot Bot
  • Оценка трудоемкости проектов разработки. Часть 2

    Тогда принял для себя решение, что считать всё абсолютно по-честному с точки зрения математики и теории вероятности — будет непосильной задачей

    Именно. Но во-первых хотелось бы, чтобы менеджеры начали это признавать и говорить об этом честно и открыто (боюсь не все менеджеры даже понимают проблему). Что их расчеты это в лучшем случае эвристики и как эвристики такие расчеты могут быть сами источниками большей ошибки (думаю это можно показать на отдельных примерах), чем ошибки в начальных цифрах. Во-вторых перестали бы гнаться за «точными» начальными оценками и применять необоснованные методы улучшения точности (имхо, Карго-культ).

    Есть большое подозрение, что очень грубые оценки дают результат не хуже, чем эти сложные методы получения оценок. И в некоторых областях те же #NoEstimates это демонстрируют. И что менеджеры подсознательно «подстраивают» цифры под их предыдущих опыт на похожих проектах. И гораздо лучше, когда они это осознают и делают явно (нет ничего плохо в использовании опыта предыдущих проектов), чем когда они придумывают сложную эвристику как случайную функцию ошибок поверх их опыта. Где хорошие результаты это просто богатый личный опыт, а не эффективность эвристики используемой менеджером.

    Рекомендую почитать Эдвардс Деминга. econ.wikireading.ru/63266

    «Эксперимент Монте-Карло с воронкой. Если начать настраивать стабильный процесс, пытаясь скомпенсировать нежелательные результаты или гонясь за сверхвысокими результатами, ситуация на выходе станет хуже, чем если бы процесс протекал без вмешательств (приписывается Уильяму Лацко).»

  • Оценка трудоемкости проектов разработки. Часть 2

    И мне таки не удалось приятно удивиться. Снова Planning poker, как улучшатель оценок и без доказательств реальной его эффективности (или хотя бы ссылок на исследования, а не анекдотов из жизни). Магические константы всюду — +50%, +70%.

    Также не каждый разработчик знает и понимает, что такое математическое ожидание.

    И снова только разработчики не умеют в математику.

    Методы Three-point estimation и PERT стары как мамонты и были придуманы из воздуха в районе 1950-1960 годов. После чего успешно кочуют из книги в книгу без желания авторов подтвердить их хоть каким-то исследованиями. Вот немного из критики:

    herdingcats.typepad.com/...​7/06/pert-analysis-r.html

    Или из pubsonline.informs.org/...​i/pdf/10.1287/ited.6.1.21
    «PERT is obviously a very useful network based model for project management. However, as the foregoing examples have shown, PERT approximations of project duration — and the associated probability statements derived from those approximations — are, at best suspect and at worst, probably downright misleading.»

    «In light of the bias long-documented in professional literature, and the nature and extent of PERT approximation errors illustrated for the simple examples explored in this paper, it seems clear that prevailing introductory PERT discussions fall short of this important objective»

    Центральная предельная теорема, как Вы сами указали, относиться только к «слабо зависимых случайных величин» это кривой перевод из вступления в русской википедии. А вот математическое определение дается для «независимых одинаково распределённых случайных величин». Задачи в ИТ легко могут иметь вероятность близкую к 100% зависимости оценки одних задач, от оценок/выполнимости других задач. Т.е это теорема вообще говоря не применима для нас даже близко. Натягивание совы на глобус — очень хочется применить, вот и применяете.

    То есть при некоторых допущениях (большое количество величин, одинаковые масштабы, слабые зависимости)

    Эти допущения в подавляющем случае ошибочны и невыполнимы. Смотри выше.

    Увеличиваем доверительный интервал

    Ваши сигмы справедливы для нормального распределения, а как мы знаем оно точно совсем не такое.

    Ох....

    Добавлю чуток позитива :) тут много и полезных советов и хорошая структура для пошаговой проверки себя. Вот за это действительно спасибо (и за ваши чек-листы)!

    Поддержал: Oleksandr Katrusha
  • Оценка трудоемкости проектов разработки. Часть 1

    В первой я пока еще ничего не складывал и не вычислял :)

    Я буду рад приятно удивиться :) К сожалению, я не знаю ни одного инструмента (трекеров типа JIRA, etc), которые бы пытались делать правильную математику. И не видел менеджеров, которые бы пытались это учитывать корректно, а не домножением на пи... Вся индустрия так работает. Но может оно и лучшему, так как правильно это делать не получиться, осталось научиться признавать случайность процессов и жить с этим. Детальней в ответе Денису ниже.

  • Оценка трудоемкости проектов разработки. Часть 1

    тут всё просто. Я не пытаюсь убедить в том, что нужно применять эту математику. Это сложно и даст мало результата. Скорее наоборот, а считаю, что нужно признать природу процессов и что гемблинг тут неизбежен. Математика против, как не старайся и оценки улучшить нельзя. Стоит радикально все упростить и перестать тратить время на попытки получения более точных оценок, так как их получение фундаментально невозможно. Я как раз пытаюсь подтолкнуть к идеи #NoEstimates

    www.youtube.com/watch?v=QVBlnCTu9Ms

    Процесс очень простой — бейте работу на сравнительно малые таски/сторисы и умножайте число задач на среднее время обработки таски (взятое оценочно или на основание истории работы команды). Всё! Это оценка на 90% совпадает с тем, что люди получают играясь в покеры или требуя детально эстимировать каждую задачу.

  • Оценка трудоемкости проектов разработки. Часть 1

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

    Вот например тут Вы рассказываете о «Ошибках в оценке вероятностей» и фактически перекладываете ответственность на разработчиков, которые не дают вам «точных» оценок и не понимают ТеорВер. При этом нет ничего о том, что оценка вероятности завершения проекта не является нормально распределенной и складывать так сроки нельзя. Более того, реальное распределение сильно асимметрично. Некоторые даже об этом пишут:

    forasoft.github.io/software-estimation

    И не потому, что разработчики «тянут» сроки, а потому, что тут природа процесса такова (нормально распределение позволяло бы на выполнение задачи за отрицательное время с ненулевой вероятностью, чего быть не может конечно. тут стоит ожидать что-то типа логнормального распределения). Кроме того, задачи не являются независимым событиями и их оценки опять же нельзя складывать как независимые переменные — это фундаментально некорректно. Деление на маленькие задачи не решает проблему с математической точки зрения, так как сумма зависимых переменных не обязана быть нормально распределенной, ну и закон больших чисел тут тоже не работает:

    rixtrema.com/...​dent Normal Variables.pdf

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

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

  • Как избежать неправильного оценивания проектов

    У меня есть опыт успешного завершения вотерфольных проектов

    А сколько всего их было и сколько проваленных? Люблю ПМ-ов, за умение обобщать по «одному» примеру. Это как обобщать выигрыш в лотерею. Хорошо бы знать процент успешности и реальную сложностью проектов. Ну и учитывая, что Вы (как и я) в аутсорсе, то будем честны, тут есть тенденция превращать месячные проекты в годовые и потом можно успешно вписаться в срок, в бюджет, и в скоуп. Поэтому, что Вы продали клиентам, как годовой проект, мало о чём говорит на самом деле. Ещё я видел как успешно «сданные» проекты клиенты потом не могли использовать. Много простора для скептицизма.

  • Как избежать неправильного оценивания проектов

    Хм. У меня нет такой статистики, но личный опыт говорит об обратном. Те пару раз, где мне везло и я попадал на проекты с отсутствие эстимейтов, это были проекты с лидом от заказчика и полным управлением проектом с их стороны. Я сейчас как раз на таком. У задач нет эстимейтов. Пару раз я сам волновался, что долго сижу над задачей без видимого прогресса и говорил свои ожидания по завершению по своей инициативе. Ещё пару раз меня лид спросил нужна ли мне помощь в задаче и что меня тормозит. Это все, что можно сказать о эстимейтах, которые у меня были за последний год... остальное время контроль это — частое закрытие задач или подзадач, периодические репорты (чем занят) и грамотный лид. И задачи у нас абсолютно разные с большим количество исследовательский задач. Некоторые занимают дни, некоторые недели и даже месяцы (бьются нами на мелкие подзадачи во время исполнение). Я потому с такой уверенностью и говорю о применимости такого подхода, что вижу это работающим каждый день. Может и не везде применимо, но точно не только для «однотипных задач». Как раз в большей степени, где много исследовательских задач и «точные» эстимейты слишком дорого и сложно.

  • Как избежать неправильного оценивания проектов

    более-менее однотипных задач

    это слишком сильное требование. достаточно более менее стабильного распределения сложности между задачами и отсутствия сверхтяжелых задач — outliers (предварительное биение задач на более мелкие это решает — это на самом деле самое важное) и достаточного количества задач в скопе (десятки и сотни задач). Дальше статистика сделает своё дело.

  • Как избежать неправильного оценивания проектов

    Оценки нужны, если у комманды ещё нет статистики — т.е когда запускается новые проект, новая команда или меняются важные условия. Но для долго живущих проектов такие оценки постепенно теряют смысл (например оценки полученные по историческим данным за 3-5 итераций скрама часто аналогичны или даже иногда точнее новых оценок сделанных методом покера). Часто достаточно точную оценку можно сделать просто по количеству юзер сторейс. Чтобы дать гарантии (а другими словами взять на себя риски за свою попытку угадать пропускную способность комманды) нет необходимости делать новые оценки нового куска работы — накопленная статистика может быть не менее точным механизмом оценок.

  • Как избежать неправильного оценивания проектов

    Есть непопулярное мнение, что можно жить замечательно и без таких оценок (движение #NoEstimates). Т.е управление проектами конечно ведется, но решения принимаются другим способом без необходимости делать «временные» оценки. Оставлю тут ряд источников для ознакомления с темой:

    www.infoq.com/...​vasco-duarte-noestimates
    www.youtube.com/watch?v=HfLzMpaV110 (Асхат Уразбаев #NoEstimates: Безоценочная разработка)
    blogs.msdn.microsoft.com/...​the-path-to-no-estimates
    softwaredevelopmenttoday.com/noestimates
    xebia.com/...​sting-without-estimation

    За отсылку к «Критическая цепь» Элияху Голдратта — спасибо. Многие менеджеры её не читали, а стоило бы.

    Поддержали: anonymous, Dmitry Derevyagin
  • Обучение без учителя — убийца математического моделирования?

    Спасибо за статью!

    Добавлю свои пять копеек.

    а вот такие вот алгоритмы уже скоро будут выучивать их сами по себе

    Я тоже люблю нейронки, но в статье вы не рассказали о многих важные аспектах таких решений. У вас всё слишком просто, прямо маркетинг нейронок... :) Вы не затронули интерпретируемости результатов, большой зависимости от гипер-параметров и сложностей их подбора, часто отсутствие сходимости, сложности контроля корректности, предвзятость (bias) моделей. Атаки на нейронки так вообще отдельная активно развивающаяся история.

    Есть мнение, что для многих задач описанный подход не работает, так как требует слишком много данных. Например известно, что роботы от Boston Dynamics не используют RL и тем более чистые нейронки.

    Есть хороший цикл о Self-Driving Cars от Welch Labs (www.youtube.com/watch?v=yaYER2M8dcs), где подробно разбирается почему современные подходы для разработки беспилотных автомобилей не используют подход End-to-end. И по мнению большого количества ML гуру — нужно всегда начинать с простых моделей, так как они часто не обладают описанными недостатками и их результаты не хуже (или не сильно, чтобы оправдать добавленную сложность). Пока нейронки хороши для определенный задач, а не как панацея и общий подход ко всему.

  • Рабочий продукт — прежде всего, или Когда не стоит увлекаться кодом и тестами

    Да нет, с аналогией тут всё хорошо. Это была отсылка к истории медицины и Земмельвейсу, но думаю вы эту отсылку не поняли. Почитайте историю. Медики тоже дико сопротивлялись этой практике и доводы против неё были абсолютно аналогичны — «это забирает важное время, а мы спасаем жизни», «у нас нет времени на эту чепуху», «роженицы умрут, если мы будем медлить». Чувствуете сходство? И хотя сейчас есть полевая медицина, где операции могут проводить в тяжелых условиях — но она это большое исключение, менее пару процентов и даже там стараются делать минимум в таких условиях и довести пациента до нормальной клиники, где будут другие правила игры.

    Медицина повзрослела, ИТ ещё нет. Все хотят быть исключением, ну не может 9 из 10 проектов быть исключением из правил... У нас слишком много проектов, которые мнят, что они на войне.

    Поддержали: Viktor Kryvyziuk, Denys Kostin
  • Рабочий продукт — прежде всего, или Когда не стоит увлекаться кодом и тестами

    Технический долг это не долг в банке. Тут с самого начала нужно правильно оценивать, что можно отложить, а что нужно исправлять сразу при любой бизнес-стратегии. С некоторыми долгами можно и первой версии не суметь сделать и загнуться в процессе её написания. Хорошая таксономия описана тут — taxonomy-tech-debt

  • Рабочий продукт — прежде всего, или Когда не стоит увлекаться кодом и тестами

    но результат одинаковый у тех и у других

    Нет, не одинаковый. Сроки эксплуатации «хрущевок» — 50 лет, сталинского типа — 150 лет. Сроки на проведение необходимого капитального ремонта тоже отличаются. Проводка и всё остальное в домах тоже резко отличаются. Чудес нет и качество стоит денег.

    одни строители могут достичь его одним путём другие другим одни дороже другие дешевле

    Могут. Но ведь нет жалеющих получить дом совсем без гарантий качества и любой вариант решения от строителей входит в стоимость постройки и является частью стоимости за жильё. Клиент активно участвует в выборе вариантов, предложенных строителями или стоителей, и тем самым менеджит риски и соглашается оплачивать качество на приемлемом для него уровне. И в этот момент это становиться его проблемой.... Делать выбор это тоже принятие участия и разделение ответственности. Нет варианта — вы там стройте как хотите, а мы оплатим только нужное нам, но все риски будете нести вы. Мечтать конечно можно, но в реальности — нет.

    Даже приемлемое качество всегда чего-то да стоит и кто-то его оплачивает. Из воздуха деньги не берутся — значит оплачивает клиент. Разница лишь в том понимает он это или нет, активно управляет своими рисками или живёт на авось и требует/ожидает от окружающих чудес.

  • Рабочий продукт — прежде всего, или Когда не стоит увлекаться кодом и тестами

    Стартрапы это пример испорченной экономики. Многие из них вообще не собираются стать нормальным бизнесом и зарабатывать деньги. Обычно они проедают деньги инвесторов и хотят кому-то продаться. Их стратегии принятия решений и то, как они полностью «забивают» на будущее своих проектов ради временного результатов не является примером здоровых/нормальных бизнес компромиссов и управления рисками. Это клиенты у которых нет интереса в самом продукте. Программный продукт тут случайным атрибут процесса доения инвесторов. Исключения бывают, но мало.

  • Рабочий продукт — прежде всего, или Когда не стоит увлекаться кодом и тестами

    Чистый код нужен только нам, чтобы легче было работать дальше.

    Ок. Следуя вашей логике — вы вероятно сидите в здание без фундамента, так как фундамент же нужен строителям, а не вам. А платить за фундамент это вообще нонсенс, ишь чего удумали... и доктора могут руки не мыть перед операцией — зачем они только время зря теряют. А чтобы люди не умирали путь просто сразу делают операции «хорошо». Вымытые руки доктора, хорошее освещение вовремя операции и т.д пациенту не нужны. Это только для доктора...

    «легче было работать дальше» имеет прямую связь с финансовыми затратами в будущем и нормальный клиент должен быть в этом заинтересован. Если клиент игнорирует реальность и управление рисками (не оплачивает вложения в борьбу с рисками) и хочет от исполнителя чудес (гарантии, что риски не материализуются), то лучше не работать с таким клиентом.

  • Проблемы вхождения в IT: почему кандидаты не подходят, или Что делается не так

    документация, практики, скоуп,.... уж не помню, когда последний раз мне бы так свезло, чтобы на проекте полноценно было бы хоть что-то одно из перечисленного. а всё сразу и качественно, так это вообще Sci-Fi.

    Поддержал: Bot Bot
  • Проблемы вхождения в IT: почему кандидаты не подходят, или Что делается не так

    Дьявол в деталях. Зависит от условий формирования проектов.

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

    А аутсорсинг может даже проект не запустить, пока нет людей. Уволить человека в середине проекта может быть проблемой. Зависит от взятых обязательств. Внутренний пул людей есть, но он может и не спасать, так как люди должны еще собеседование с заказчиком суметь пройти. А со стороны заказчика или снова «желание того, что выгодно и удобно» или уже их лиды с теми же обширными требованиями.

    Обучение людей стоит денег и вполне понятно желание экономить. Но очень неприятно, что в последствиях этого автор статьи обвинил исключительно лидов. Явление с плохими требованиями и собеседованиями явно имеет массовый характер и существует не только в Украине. Я не верю, что у нас Все лиды плохие и дружно саботируют процессы из сомнительных интересов и личной глупости. Вместо выявления системной проблемы автор нашёл крайних. Оказывается, это положение всем невыгодно и только лиды все портят. Теперь то он научит нас как правильно жить и что делать... Так уже и вижу, как завтра все начнет улучшаться благородя глубокому анализу в его статьях.

    Поддержал: Сергій Назаревич
  • Проблемы вхождения в IT: почему кандидаты не подходят, или Что делается не так

    А взагалі, якщо вам не потрібна людина з вузькоспеціалізованим скілом, який вийде на роботу завтра і зробить, те, що потрібно «на вчора»

    faamg компании могут себе позволить обучать джунов, так как более менее уверены, что человек сразу от них не уйдёт. Имидж работает на них. И даже они мотивируют сотрудников обещанием акций через N лет работы. Ну и их собеседования с алгоритмами и другими формами бега через препятствие тоже очень спорная штука. Действительно ли в реальной работе потом все эти алгоритмы сами ручками пишут, на доске, на время.... Остальным нужны люди именно «на вчера». Чтобы хотя бы не приносили убытки. В собеседованиях много глупостей и их можно и нужно проводить лучше. Но пока компании ожидают мгновенной отдачи, то собеседования так и будут адом. И я не вижу экономических причин для компаний хотеть настоящих джунов, а не просто зарплатных.

← Сtrl 12 Ctrl →