Comments 128
15 мисок риса от товарищей разработчиков этому господину и -15 социального рейтинга от господ менеджеров
Мне нравиться вариант с оценкой через проработку архитектора и аналитика
Архитектор с помощью руководителя проекта (владельца продукта) делает границы технической реализации (определяет каналы, компоненты, технологии и технологические риски) - такие архитекторы есть, я их видел
Аналитик делает бизнес процессы (по шагам) и схему макетов (конечно лучше с дизайнером)
На основе результатов нарезаются технические и бизнес Истории
Итог отдаётся лидам разработки и тестирования (эти люди обычно знают реальные возможности разработки, они же знают их темную сторону), можно в 2-3 независимым, если есть возможность.
Такая оценка близка к правде
Соглашусь, что идеальных архитекторов, аналитиков, разработчиков и тестировщиков не бывает, но если у них горят глаза, обычно результат отличный
Это если есть архитектор и аналитик. Часто - это одно и то же лицо и, к сожалению, ты.
Нужно как можно скорее делать MVP и напильником его, напильником, пока поток денег от заказчика не иссякнет.
Никогда нельзя заложить достаточно гибкости, чтобы не пожалеть об отсутствии гибкости в будущем...
Тут тоже есть инструмент, он немного спорный, но мне помогает
Дерево целей, это подход когда ты по ТЗ или наброскам ТЗ (таких к сожалению больше) обозначаешь цели и минимальные шаги по достижению. Сверяешь а бьется ли, бывает, что не бьется:))) И наполняешь набор из Историй
Тут уже только экспертиза и уточняющие вопросы разработке
Инструмент хороший, но надо потренироваться:)
Осталось оценить время на оценку)))
С одной стороны, бизнесу надо знать, сколько займёт разработка фичи, причем как можно точнее. И это понятно — ведь надо как-то принимать решения, чтобы сравнить предполагаемые доходы и расходы и достать деньги в нужном количестве.
Если бы всё фичи были бы заранее известны, пронумерованы, поименованы и закодированы, то не надо было бы ничего заранее разрабатывать. Неразрешимое противоречие заключается, скорее всего, в том, что все всегда начинают с чистого листа (как будь-то до нас ничего не было и даже мы сами ничего ещё не делали, хотя... нет! делали! есть же "легаси"!), но никто не хочет пронумеровать, поименовать и закодировать.
А так было бы здорово иметь каталог фич (типа Периодической таблицы химических элементов) и знать заранее все характеристики.
С другой стороны, разработка порою
в душе не е...вообще не знает, сколько надо времени, особенно если
новая функциональность нетипична
есть зависимости на другие команды
будет задействована новая технология
ТЗ надо сильно уточнять
надо разобраться в логике легаси-кода
Сразу возникает вопрос. Почему функциональность какой-то фичи может оказаться нетипичной? Разве набор фич не может быть ограниченным? Возьмите какую-нибудь задачу. Попробуйте расписать разного рода сценарии. Разве их не будет весьма ограниченное количество? Вот и надо один раз закодировать каждый сценарий (в виде рабочего компонента) и потом брать из готового каталога. Разве не так?
А команды? Кто распределял нагрузку между командами, что бы были такие патологические зависимости? Зачем же существует модульное проектирование? Неужели фича размывает границы между модулями? Если это так, то надо. вообще, новую систему делать. Разве не так?
Новая технология? Стоп. Когда что-то разрабатывается, то, разве, не утверждается список используемых технологий? Каждая новая технология содержит свой уникальный набор собственных внутренних нетипичных фич (см. п.1), которые будут размывать изначальную модульность (см. п.2).
Уточнение ТЗ представляется (лично мне) признаком ошибочности его составления. Например. (Я немного утрирую.) Сначала создавалась система, которая не предполагала никакого участия пользователей в редактировании материалов некоторого сайта. Затем, захотелось добавить новую "фичу" — редактирование. Но это же — совершенно другая система, другая идеология! При этом, заранее можно сеть и просчитать каждый вариант системы, для каждого варианта предложить свою архитектуру и разговаривать с заказчиком на уровне архитектуры, не на уровне фич. Разве не так?
А ещё пресловутое "легаси"... Все привыкли к тому, что берётся и правится уже существующий действующий код. Только зачем так делают? Меняется, ведь, спецификация системы. Значит, нужно повторить те же шаги. что и были раньше сделаны, но уже с новыми вводными данными. Тут ещё проблема в том, что всё делают в рамках одного языка программирования. А система должна описываться (проектироваться) на одном языке, а реализовываться при помощи генерации программного кода на другом языке. И править нужно первичное описание, а не конечную реализацию. Разве не так?
Попробуйте расписать разного рода сценарии. Разве их не будет весьма ограниченное количество? Вот и надо один раз закодировать каждый сценарий (в виде рабочего компонента) и потом брать из готового каталога. Разве не так?
Их будет весьма ограниченное количество, это правда. Только бизнесу то нужен 1. А на проработку всех сценариев вы потратите х100 ресурсов. Я не видел пока бизнеса, который на такое согласен.
С таким подходом ни один стартап не взлетит...
Противоречие: бизнесу абсолютно необходимо оценивать качество и скорость работы программиста, но это абсолютно невозможно сделать объективно.
Учёные давно занимают вопросами построения всевозможных систем. И всё, что подлежит оценке, оценивается (включая и временные затраты). Только никто этим не пользуется при разработке ПО.
В этом смысле, было бы крайне любопытно посмотреть на руководителя какой-нибудь конторы, который возьмёт только что сделанную и сданную заказчику успешно функционирующую систему, разложит по полочкам её составные части, выявит все зависимости, выделит смысловое ядро и построит движок, на котором могла бы "крутиться" такая система. А потом сравнит реальные произведённые затраты и те затраты, которые могли бы быть потрачены, если бы вот эта самая постфактум-разработка была бы проделана в реальности. "Движок" — это и есть то, что фактически нужно сделать. Вы продаёте заказчику "движок". Меняется ТЗ — меняется и "движок". Хотите ещё большей гибкости — создавайте "дижок" "движков". И, заметьте, это всё предельно очевидно. Разве не так?
В общем, на мой взгляд эти противоречия абсолютно неразрешимы ...
Самое главное противоречие — это противоречие между глубокой практичностью программистов на деле, и совершенной абстрактностью тех же программистов на словах. Почему, когда программист хочет поделиться какой-то проблемой, он произносит только общие слова? Почему программист не приводит конкретных примеров? Можно было бы посмотреть реальный проект, оценить способы и сроки исполнения, попробовать сделать то же самое при помощи других подходов, сравнить результаты, сформулировать выводы. Разве не так?
Потому что это невозможно. Реальный проект - это десятки тысяч тикетов, каждый из которых может содержать скрытые подзадачи. Почти не бывает идеально описанных тикетов, всегда есть подразумевающийся контекст, допущения, упрощения, просто ошибки, и "устные договоренности", возникшие во время разработки, и нигде не зафиксированные.
Берете два с виду одинаковых тикета. Но один делал Вася, а другой - Петя. У них разный опыт. И они выбрали разные пути решения. И Вася был после кранча/болезни, а Петя после отпуска. И кто-то внешний, менеджер на приемке, тестировщик на тесте, лид/коллега на ревью указал им на разные недостатки. И Вася пилил фичу до рефакторинга всей подсистемы, а Петя - после. А ешё за это время поменялся контракт взаимодействия с внешним сервисом. И оказалось что когда Петя закончит фичу - девопсы сломали тестовый стенд, и Петя потратит лишние пару часов на поиск причины.
Всё это и многое другое не будет учтено при оценке (и в гипотетической общей табличке оценок)
Потому что это невозможно.
В обычной ситуации, скорее всего, невозможно. Но мы с Вами тут сидим и рассуждаем, что-то себе представляем. то есть — находимся в необычной ситуации.
Реальный проект - это десятки тысяч тикетов, каждый из которых может содержать скрытые подзадачи.
Разве процесс проектирования не заключается в том, чтобы сделать все задачи явными?
Почти не бывает идеально описанных тикетов, всегда есть подразумевающийся контекст, допущения, упрощения, просто ошибки, и "устные договоренности", возникшие во время разработки, и нигде не зафиксированные.
Да, конечно. Но разве процесс проектирование не направлен на то, чтобы (в пределе) формализовать все "устные договорённости"?
Берете два с виду одинаковых тикета. Но один делал Вася, а другой - Петя.
Это у Вас есть какой-то тикет. Но, представьте, что нужно что-то сделать, так надо, сначала, назвать, что именно. Мы должны указать место, где должны быть произведены изменения, и описаны сами требуемые изменения. Как только это место найдено в спецификации (и на языке спецификации), Вася или Петя делают одно и то же и закрывают тикет. Ведь, тикет явно указывает, что нужно сделать, что и в какую сторону изменить. Разве не так?
И они выбрали разные пути решения.
Почему? Неужели задача, связанная с обрабатываемым тикетом, столь велика, что допускает множество решений? Надо же понимать, что различные пути решения затрагивают различные аспекты уже существующей архитектуры, а какие-то требуют её изменения. Не все решения оказываются, таким образом, допустимыми.
И Вася был после кранча/болезни, а Петя после отпуска.
формализация процесса разработки ПО (на мой непросвещённый взгляд) должна гарантировать независимость разработки от такого рода привходящих обстоятельств, поскольку, при необходимости что-то сделать, каждый будет заглядывать в одни и те же места спецификации, руководствоваться одними и теми же положениями общих для всех документов.
И кто-то внешний, менеджер на приемке, тестировщик на тесте, лид/коллега на ревью указал им на разные недостатки.
Вполне естественно, что, если Вася и Петя пойдут разными путями, то они получат и разные результаты. Вопрос в том, что должно происходить в тот момент, когда каждый из них принимает какое-то решение и собирается его реализовать. Вот тут и нужно провозгласить, что именно планируется сделать, и выяснить потенциальные недостатки, не дожидаясь конечного результата. Как можно пытаться кодировать то, что может быть забраковано? Пускать в реализацию, кажется, можно только то, что принято и утверждено.
И Вася пилил фичу до рефакторинга всей подсистемы, а Петя - после.
Страшное дело! А зачем Петя пилил? Система прошла рефаторинг? Отменить все старые тикеты!
А ешё за это время поменялся контракт взаимодействия с внешним сервисом.
Кранты! Снизу постучали. Опять.
И оказалось что когда Петя закончит фичу - девопсы сломали тестовый стенд, и Петя потратит лишние пару часов на поиск причины.
Простите, а почему у Вас один и тот же стенд для старой и для новой системы?
Всё это и многое другое не будет учтено при оценке (и в гипотетической общей табличке оценок)
Если общая таблица оценок существует (построена), то варианты разработки выбираются из неё и только из неё. Если имеются неучтённые факторы, то нужно строить новую таблицу оценок. Всё, о чём я говорю, это вопросы целостности (непротиворечивости) описания. Чрезвычайно сложно действовать в раздробленном мире, где ТЗ меняется на ходу, и никто ничего не может спланировать наперёд.
Честно говоря, вы похоже не участвовали в реальной разработке в реальных компаниях )) Сразу прошу у вас прощения, за такой переход на личности.
То что работает в мире "идеальных сферических сотрудников в вакууме" разбивается о скалы реальности.
Чрезвычайно сложно действовать в раздробленном мире, где ТЗ меняется на ходу, и никто ничего не может спланировать наперёд.
за такие слова в современно agile мире выгоняют с собеседований. Хотя это и правда так. Но так уж устроен мир разработки, такие тенденции сейчас на хайпе. И да, вы правы, это сложно, быть разработчиком. Ну так за решение сложностей компания и платит.
Ведь, тикет явно указывает, что нужно сделать, что и в какую сторону изменить. Разве не так?
Идеальный тикет именно такой. Жаль их не существует. Ибо проработка тикета до списка однозначных действий - и есть больше половины реализации. Об этом кстати сказано в обсуждаемой статье.
Разве процесс проектирования не заключается в том, чтобы сделать все задачи явными?
проектирование проводится на нескольких уровнях. И детальное проектирование на нижних уровнях часто входит в тикет, или само по себе является отдельным тикетом.
Неужели задача, связанная с обрабатываемым тикетом, столь велика, что допускает множество решений?
Да, а что вас удивляет? иначе программисты были бы не нужны, весь код бы генерировался из шаблонов. Вы не поверите, но когда я пишу письмо кому-нибудь, и мне нужно написать всего одну первую строчку приветствия (строго описанный тикет, не так ли?) у меня и то будет с лету 5-10 вариантов. А если хорошо подумать, то и гораздо больше.
если Вася и Петя пойдут разными путями, то они получат и разные результаты.
результат заказывает бизнес. И он часто оочень примерно знает какой ему нужен результат. Допустим бизнес хочет а-а-а-а-автомобиль. И даже четко описывает требования - 4 колеса, 4 двери, двигатель, коробка передач, руль, сиденья, фары и т.д. и т.п. Угадайте сколько возможных вариаций автомобилей можно ззапроектировать/произвести? Бесконечное количество. И кстати - они ВСЕ будут формально соответствовать исходным требованиям. А время на реализацию проекта будет разным. Т.е. разный результат - это нормально, пока он решает задачи бизнеса.
Как можно пытаться кодировать то, что может быть забраковано? Пускать в
реализацию, кажется, можно только то, что принято и утверждено.
Манифест agile с вами несогласен) Любой код, любые принятые и утвержденные требования в будущем могут измениться и быть "забракованы". Сегодня вы пилите утвержденную фичу, а завтра изменилась ситуация на рынке, и фича стала не актуальна, или должна быть видоизменена.
Страшное дело! А зачем Петя пилил? Система прошла рефаторинг? Отменить все старые тикеты!
с какой стати-то отменить? т.е. после каждой выполненной задачи сразу стирать весь бэклог? на которые с вашим подходом убиты тысячи часов, чтобы декомпозировать и расписать и оценить всё до мелочей?
Простите, а почему у Вас один и тот же стенд для старой и для новой системы?
Простите, но мир так устроен. Есть компании, где всё идеально, и под каждую таску автоматически разворачивается отдельный тестовый стенд, со всеми сотнями сервисов, инфраструктурой, петабайтами обезличенных production-like данных... И есть реально существующие компании где часто нет тестеров, нет стендов, есть фиксированное количество стендов, стенды отличаются от прода, каждый стенд уникален как снежинка, развернуть и настроить стенд занимает от недели до месяца... Есть ли у компании ресурсы (а это может быть очень дорого) или есть ли руководства понимание/желание сделать хорошо - зависит не от разрабов и не от тимлидов, и даже не от ПО и ПМ-ов.
Честно говоря, вы похоже не участвовали в реальной разработке в реальных компаниях )) Сразу прошу у вас прощения, за такой переход на личности.
Совершенно верно. Но переход на личности приветствую. Сейчас это очень нужно.
... Да, а что вас удивляет? иначе программисты были бы не нужны, весь код бы генерировался из шаблонов.
Для меня вопрос в том, что именно идёт в дело, что именно превращается в код. Придумать несколько решений можно, но почему-то Петя делает одно, а Вася — другое. Кто-то же даёт отмашку? Или каждый поработал самостоятельно и принёс решение?
Бесконечное количество. И кстати - они ВСЕ будут формально соответствовать исходным требованиям.
Мне трудно иметь дело с отвлечёнными примерами. Всё-таки, кажется, что на практике в Ваших тикетах встречаются более конкретные указания.
Манифест agile с вами несогласен)
Скорее всего, это так и есть. Но я не стремлюсь специально вступать с чем-то в противоречие. Я просто рассуждаю. Могу войти и в противоречие.
Сегодня вы пилите утвержденную фичу, а завтра изменилась ситуация на рынке, и фича стала не актуальна, или должна быть видоизменена.
А вот это уже очень интересно. Допустим, произошли изменения. Какие-то. Весь вопрос в том, что с эти делать. Как Вы будете "выпиливать" фичу из готового продукта? И какие варианты видоизменения могут считаться допустимыми? Как быть. если эти изменения потребуют видоизменения архитектуры самого приложения? Там, ещё, зависимости разные...
т.е. после каждой выполненной задачи сразу стирать весь бэклог? на которые с вашим подходом убиты тысячи часов, чтобы декомпозировать и расписать и оценить всё до мелочей?
Подождите! В Вашем примере "Вася пилил фичу до рефакторинга всей подсистемы". Зачем же пришёл Петя уже после рефаторинга и снова стал пилить ту же фичу? Давайте уточним условия задачи.
Простите, но мир так устроен.
Да он устроен так, как устроен. Вы правильно это описываете. Даже я это понимаю, хотя опыта соприкосновения с этим миром не имею. (Когда-то давно соприкоснулся, но... один раз не считается.)
Меня же, например, интересует, почему положительный опыт не тиражируеся. И что было бы, если бы, например, agile не было бы? Что было бы вместо agile? Старый-добрый каскад? Всё крутится вокруг того, если способ сделать мир немного проще.
Но разве процесс проектирование не направлен на то, чтобы (в пределе) формализовать все "устные договорённости"
Формализация договоренностей - это, собственно, и есть написание кода. И описание тикета всегда условно, и всегда содержит много неявных условий. Поэтому не выйдет.
И ещё. Давайте не будем ходить далеко.
Представим себе, что в нашем ведении находится разработка форума, вроде того, где мы сейчас сидим. Текущий способ редактирования сообщений представляется не очень удобным (нужно куда-то бегать мышкой, "скроллить" и ловить всплывающие меню). Хочется как-то модернизировать. Но как?
Ключевой вопрос — это вопрос о том, что является (должно быть) единицей обработки. Традиционно считается, что единицей обработки является отдельное сообщение (пост). Мы можем вручную вырезать нужный фрагмент и оформить цитату. Но удобнее сразу иметь возможность прокомментировать конкретный фрагмент, неправда ли? Для этого надо, чтобы единицей обработки было отдельное предложение. Тогда каждый пост можно будет развернуть в виде набора атомарных постов, и реализовать наборы типовых операций над отдельными предложениями или их наборами. В результате, Вы получаете обратно Ваш текст, но уже размеченный Вашим собеседником. И так — для каждого Вашего собеседника. Да и в пользовательском интерфейсе не надо будет решать проблему линейного/иерархического отображения реплик, а пользователь сам будет определять, в каком виде реплики будут отображаться (автоматически).
Выбор единицы обработки определяет архитектуру системы.
Или, другой например. Вот, когда мы смотрим ленту Хабра и переходим на новую страницу, что происходит? К БД посылается запрос, получить соответствующий набор статей на момент совершения запроса. Это означает, что, пока Вы сидите на одной странице, проходит время, за которой на Хабре появились новые статьи, происходит сдвиг. В результате, Вы снова получаете ряд уже виденных Вами на предыдущей странице статей. Спрашивается, это что: "баг" или "фича". Нужно ли это исправлять? Например, можно было бы запомнить самую последнюю статью на момент захода пользователя на Хабр, а все новые статьи отображать на отдельной странице ("новые"). И тогда не будет никаких сдвигов, всё будет логично и понятно. Разве не так?
Но! Кто-то сделал то, что сейчас работает? Интересно, как этот разработчик объяснял себе странное поведение ленты? И что будет делать этот разработчик, если дать ему новый тикет, попросив его переделать отображение ленты?
Выбор единицы обработки определяет архитектуру системы.
Мне кажется, вы уходите куда-то не туда. В любом форуме есть бек и есть фронт. Если мне нужно реализовать возможность цитирование предложений (хотя на самом деле удобнее выделенного текста, так как выделить преложение из поста очень нетривиальная задача, которая не решается алгоритмически в общем случае) я это сделаю на фронте, а бек получит всего-лишь набор тегов с цитатой и новым сообщением. С точки зрения 99% программы никакой "единицы обработки" в виде предложений не будет, а будет просто механизм добавления нового поста под старым.
ИМХО, у вас оверинженериг получается.
Жаль, что в статье ничего нового. Вопрос простой: а как решают в других инженерных профессиях? Разработка была задолго до IT, и тоже как-то надо было сроки угадывать, даже более строго, прототипирование и тестирование в железе жручее и тоже плавающее.
Да никак не решают. Вы же слышали про долгострои и переносы сроков в куче других областей. И в самолетостроении, машиностроении, и гражданском строительстве, и в "законотворчестве", искусстве. С ростом сложности, все больше неопределенности. Чем дольше срок, тем больше погрешность. Чем больше творческого и умственного труда, тем больше неопределенности. Зачастую менеджмент, просто не видит разницы между программированием и простым механическим, физическим трудом.
"Законы Мёрфи", наверное, тоже все читали.
Разница многих областей с ИТ в том, что там часто делают "то же самое" с небольшими изменениями. А в ИТ почти всегда хотят уникальное. Поэтому мы сравниванием "производство" vs "полноценное r&d + производство". И вот это r&d все меняет. И оценке поддается очень плохо, т.к. является "грязной проблемой".
Собственно, r&d всегда такой в мире. Просто мы ошибочно равняем ИТ к производству.
А в ИТ почти всегда хотят уникальное.
Вот почему очень нужны примеры. Хочется увидеть это уникальное.
У меня есть четыре банковских приложения и они все разные. Иногда даже разный функционал.
А Вы можете кратко описать эти приложения (если есть возможность ничего не разглашать)? В чём принципиальная разница между ними? И можно ли найти что-то общее (в плане реализации)?
Попробую описать (очень примерно):
ВТБ: на главном экране вверху ссылка на репозиторий, где можно скачать обновлённое приложение, потом идёт витрина с продуктами банка и только ниже список моих счетов. Потом идёт список возможных способов оплаты (СПБ, QR). Ниже идёт список уникальных продуктов банка и курс валют. Кроме того есть выплывающая снизу навигационная панель.
Росбанк: на главной сначала идёт список счетов и только потом витрина с услугами, потом поиск банкоматов. Вместо перечня способов оплаты идёт меню «быстрые действия», потом курсы валют. Панели навигации нет совсем, да и в принципе главный экран беднее экрана ВТБ. Хотя и не факт, что это плохо.
Альфа-банк: на главной вверху ссылка на репозиторий, потом список счетов, но не полностью. На полный список ведёт отдельная ссылка. Вместо витрины идут «персональный предложения банка», типа не «кредит под 100500% годовых», а «Вам одобрен кредит под всего 100500% годовых». Ниже идут предложения типа «Пригласи друга и выиграй 1000₽». И ниже идёт ещё что-то вроде смеси витрины и рекламы.
Панель навигации тут не всплывающая, а фиксированная. И там есть отдельная страница «Витирина».
Тинькофф описать сложно. Сравнивать его приложение с приложениями других банков это как сравнивать кнопочный телефон со смартфоном. В разное время там могут появляться и казуальные игры, и статьи по психологии и многое другое. В него встроены сервисы для покупки любых билетов от кино до самолётов, доставки еды и чёрт знает чего там на самом деле нет. Есть даже бот-секретарь, который отвечает на телефонные звонки (если его включить).
В плане реализации там наверное много общего. В конце концов основной функционал один и тот же (открыть/закрыть/пополнить счёт, перевести деньги) но вот второстепенные функции, дизайн и логика навигации по экранами (а соответственно и логика приложения) сильно разные.
В других инженерных профессиях это решается, тем что делается примерно одно и то же, постепенно, итеративно с "минимум научной новизны" на каждой итерации изделия. Или по крайней мере балансировкой, и пониманием что лишняя "научная новизна", может утопить проект.
Недавно на "Радио-Т" было "правило 80/20 для контракторов": на любую задачу возьми минимум 80 часов, а потом умножь их на 20 :))
Я не помню как называется феномен когда много людей давали оценку количеству конфет в большой банке. Суть в том что никто не угадал при чем сильно не угадали, но участников было достаточно, что бы среднее значение оценки было ну очень близко к точному. Попросите много людей анонимно оценить срок И степень уверенности оценки. Дальше переведите уверенность в диапазон от 0 до 1. Поделите оценку на уверенность. Сложите все вместе и посчитайте среднее. Если феномен имеет место быть в реальности то чем больше оценок у вас будет тем точнее будет результат. Анонимность важна т.к. устраняет корреляции в оценках, но это противоречит устоявшейся практике командной оценки где нужна единогласная оценка. Этот способ организационно сложный и требует понимания всех участников зачем они это делают, ведь всегда нужно больше тасков закрыть, а эта деятельность не помегает их закрывать поэтому проще читать ТЗ по диагонали как можно быстрее и дать не совсем уж явно рандомную оценку тоже побыстрее, что бы наконец вернуться к текущим задачам.
У нас часто так, планирование спринта, покер, все показывают оценки, часто бывает разброс и большой. Крайние оценки начинают спрашивать, почему вы видите задачу не так как другие, суть в том что вежливо склоняют через переговоры прийти к единому мнению. А зачем вам всем обезличенное единое мнение? Попросили мое мнение я его дал, а потом такие ну не очень то твое мнение хорошее, давай меняй. Я в такие моменты вообще не спорю сразу соглашаюсь на любую предложенную цифру, потому что во первых это не мое мнение я свое не поменяю, а во вторых задача будет сделано не раньше чем будет сделана, а про цифры все забудут и очень быстро. Мало того после решения начать работу над задачей на эти цифры вообще никто не смотрит. Так зачем тогда тратить время на обсуждения? Просят помочь с оценкой я стараюсь как могу, но почему то у меня остаётся неприятное ощущения от процесса и помогать уже и не особо то и хочется. Твоя оценка выбивается давай ка ты ее поменяешь на удобную нам, да пожалуйста, а зачем тогда мое мнение спрашивали?
Статистический эффект имеет место быть, однако такой способ будет работать, только если исходить из предположения, что все в команде будут давать честную оценку. Т.е. ту, которую считают реальной. Если кому-то выгодно завысить оценку срока выполнения, а в целом это выгодно всем кто не собирается надолго задерживаться в компании, так как нужно будет выполнить тот же объём работы за более продолжительный промежуток времени. В итоге бизнес станет менее конкурентоспособным и это в конце концов негативно отразится на доходах компании. Причём отделить саботажников от реально понимающих людей нереально так как у нас анонимность.
Усреднение имеет смысл, если центр распределения оценок близок к реальному результату. Если большинство ошибается, или на самом деле право некоторое меньшинство, усреднение нечем не поможет.
Проблема в том, что даже в адекватно прописанном в ТЗ и знакомом по опыту функционале всегда остается много неопределенности, если даже вам вдоль и поперек знакома фича по предыдущему опыту - это вовсе не означает что вы:
Точно идентифицировали фичу - вполне может быть, что заказчик подразумевает нечто иное.
Фичи практически никогда не бывают одинаковыми - иначе, как и было подмечено, разработчики бы тупо собирали ПО из давно сделанных кирпичиков - но нет, каждый раз свои нюансы.
Практически ни один проект не обходится без внесения изменений в процессе разработки - как бы там ни божился заказчик и как бы опытен ни был аналитик/архитектор.
Из известных мне и более-менее рабочих способов гадания на сроки - это закладка риска: то есть определяешь сколько по твоему мнению на разработку фичи нужно времени и добавляешь на неопределенность еще 15-20% времени - как раз на то, что фичу неправильно понял, фича будет меняться и/или возникнут другие непредвиденные обстоятельства.
В целом это работает, но не в минимум двух случаях:
Нет опыта реализации подобного - соответственно не от чего отталкиваться. Частично решается тем, что проводишь экспресс изучение темы - хотя бы где и что надо узнать из технологий и сколько времени уйдет на уже изучение исходя из объема материала - плюсуешь к времени разработки. Работает плохо, но лучше, чем ничего.
Большие системы подчиняются законам математического хаоса, бишь нелинейны - и все факторы неизвестности в них вызывают мультипликативный рост сложности. Если проект большой - даже при хорошей декомпозиции на задачи это не значит, что общее время выполнения этих задач влезет в те самые 15-20% прибавки на риск - увы, но тут разброс растет в геометрической прогрессии. Поэтому, собственно, рассчитывать на точность оценки крупного проекта вообще не стоит - тут надо идти итерациями, от MVP.
В разработке ПО существует неразрешимое противоречие — это оценка сроков.
Просто этой конкретно проблемой часто не занимаются из-за лени менеджеров и прочих ЛПР и "особенностей" бизнеса. С технической точки зрения можно попытаться решить приблизительно следующим образом
Требуем разработчиков оценивать время выполнения работ, собираем статистику
Чтобы устранить влияние прочих факторов, даем стимулы для разработчика:
Выполнишь задание быстрее - получишь больше
Добавляем еще за достоверную оценку времени своей работы (если угадал - получил премию за оценку)
После сбора статистики строим вероятностную модель распределения оценок
Вводим в эту модель функцию риска неправильной оценки сроков (бизнес-требования)
Получаем конечную цифру срока для заказчика
Тут может показаться, что награждать разработчиков за быстрое время выполнения - скользкий путь, но надо понимать, что тут как раз уже наступает реальное противоречие между хотелками бизнеса и приоритетами разработчика. Как эту проблему решать - это уже немного другой вопрос. Во всяком случае стимулы из п.2 нужны для того чтобы
не возникало желания работать "на расслабоне"
у разработчика не возникало желания оттянуть время выполнения до своей оценки, чтобы получить премию за оценку
в переводе: берем тык пальцем в небо от разраба, добавляем разброс разных тыков, получаем средний разброс тыка, берем статистику тыков, считаем тыки нормально распределенным значением, 2-3 разброса тыков от тыка, и вдруг получаем конечный срок.
считали на тыках а получили срок?)
это не работает
Это работает, просто бизнесу нецелесообразно заниматься этой ерундой (в большинстве случаев). Поэтому никто не занимается и продолжают тыкать. Никто не хочет переводить вопрос из разряда словоблудия менеджеров в техническую плоскость, да и не надо.
Я вообще в первом комментарии не написал, что стоит так поступать. Я написал, что стоило бы сделать, если технически попытаться решать такой вопрос.
докажите что это работает, и вы перевернете индустрию.
спойлер: вы не докажете.
то что вы делаете - вы строите модель распределения тыков. причем тут срок?
Чтобы доказать что это работает, нужно лишь доказать, что оценка времени выполнения задания программистом дает информацию о реальном времени выполнения им задания.
Вы утверждаете противное? Во всяком случае, строго говоря, нужно исследование на состоятельность этой нулевой гипотезы.
ну так вперед, удачи в исследовании!
нужно лишь доказать что оценка времени выполнения задания программистом дает информацию о реальном времени выполнения им задания
дает, конечно: коэфициент корелляции где-то между 0 и 1 в каждом отдельном случае
Вам же объяснили уже, что в большой системе - нелинейные зависимости между входящими данными и результатом. Так же точно происходит с предсказанием погоды - это же уже исследовалось, и даже понятно почему так происходит - погуглите Эдварда Лоренца с его "эффектом бабочки".
Требуем разработчиков оценивать время выполнения работ, собираем статистику
статистика - это когда у вас есть данные о распределении соотношения значений величны какого-то выходного параметра, и значений каких-то входных параметров. Если что это "неканоничное" определение.
Так вот входные параметры - это буковки, которые составляют описание таски. Плюс текущее состояние проекта и его кода. Плюс состояние документации. Плюс опыт и знания разрабов. И вот уже это - неразрешимая проблема. Вы просто не сможете качественно классифицировать входные параметры, чтобы по ним собирать статистику значений выходных параметров.
Чтобы устранить влияние прочих факторов, даем стимулы для разработчика
это просто смешно. Вы недооцениваете разрабов. Любые подобные метрики "оптимизируются" на раз-два. У вас начнётся банальная "инфляция" оценок - ставишь огромную оценку, и у тебя есть время и для того чтобы "оценка" оказалась "верной", и даже чтобы "выполнить задание быстрее". Возможно даже будет оставаться время на сериалы и леваки. Хотя тут у вас прямо очевидное логическое противоречие. Ведь если выполнил быстрее - значит оценка неверна %))
После сбора статистики строим вероятностную модель распределения оценок
И она вам показывает что:
одна и та же задача "добавь в систему новый отчет" может занимать как 2 часа, так и 2 недели, так и 2 месяца. Средняя оценка в 2 недели - в большинстве случаев будет неверной.
"вероятностная модель распределения оценок" вообще не совпадает с результирующим распределением времени затраченного на выполнение.
Получаем конечную цифру срока для заказчика
которая имеет мало общего с реальностью.
Любые подобные метрики "оптимизируются" на раз-два. У вас начнётся банальная "инфляция" оценок - ставишь огромную оценку, и у тебя есть время и для того чтобы "оценка" оказалась "верной", и даже чтобы "выполнить задание быстрее".
Вы не привели контрпример. Если разраб будет оттягивать оценку на поздний срок, он будет гораздо больше терять за медлительность работы. Выплаты разрабам за быстроту работы не связаны с их оценками.
Хотя тут у вас прямо очевидное логическое противоречие. Ведь если выполнил быстрее - значит оценка неверна
Нет противоречия. За быстроту работы получаете больше, чем теряете за неугаданную оценку.
Выплаты разрабам за быстроту работы не связаны с их оценками.
А что такое "быстрота работы"? Разве не выполнение в соответствии с оценкой или быстрее? И если нет оценки - то нет и "быстроты".
Или вы предлагаете количество набираемых символов в секунду считать?
Я повторяю опять. Прочитайте https://habr.com/ru/articles/749206/#comment_25770458
Я не рекомендую так поступать. Я лишь описал возможный способ решения проблемы технически. Я не утверждал что это делать целесообразно. Как судя по тому что получилось нецелесообразность в большинстве случаев бросается в глаза. Если у вас критика технического подхода описанного выше - приводите контрпримеры. Если можете написать лучший технический подход - напишите какой.
Вы в своем "техническом" подходе вводите какие-то абсолютно нетехнические термины, вида "быстрое время выполнения" (время не бывает "быстрым", мы же не теорию относительности обсуждаем) , "быстрота работы" и "медлительность работы". И даже не можете объяснить что они значат и как именно вы предлагаете их считать.
И почему-то предлагаете мне "сперва добиться" и придумать техническое решение задачи, которая на данном этапе развития не имеет такого решения (о чем и пишет автор обсуждаемой статьи, и с чем я согласен, исходя из своего личного многолетнего опыта)
Я в одном комментарии не мог всю теорию вывести, просто привел приблизительное направление решения. Естественно точно, с доказательствами я не смогу на 10 минут все написать. Вот именно из-за этих нюансов, нецелесообразность бросается в глаза. И в большинстве случаев не надо заниматься этой ерундой.
Выплата разрабу - некая монотонно убывающая функция от времени выполнения задания.
Премия за оценку - тоже некоторая функция от разности между оценкой и реальным значением. Соответственно, нужно подобрать эти функции так чтобы у разрабов не возникало желания схитрожопить с манипуляцией оценками и времени своей работы.
И почему-то предлагаете мне "сперва добиться" и придумать техническое решение задачи, которая на данном этапе развития не имеет такого решения
Дело не в том, что она не имеет решения. Дело в том, что ее решение вероятно оказывается сложнее чем сам процесс разработки. И даже если ее решить и получить результат, вероятно мы не получим значительного выигрыша с точки зрения бизнеса, по сравнению с затраченными усилиями или прочими подходами. На выходе получаем - нецелесообразность.
Есть большая разница между "проблема не имеет решения" и проблема имеет решение, но решать ее нет смысла в определенном контексте.
Вы в своем "техническом" подходе вводите какие-то абсолютно нетехнические термины, вида "быстрое время выполнения" (время не бывает "быстрым", мы же не теорию относительности обсуждаем) , "быстрота работы" и "медлительность работы". И даже не можете объяснить что они значат и как именно вы предлагаете их считать.
Согласен, термины не технические. Если у вас есть желание дальше в эту дыру лезть, могу попытаться дать более строгие определения.
Идея в том, чтобы
"Нагрузить разрабов", для этого ввести стимул оплаты в зависимости от времени выполнения. Соответственно, у разраба нет резона манипулировать своей работоспособностью, так как это ему стоит денег.
Ввести стимул за точную оценку выполнения задания, чтобы разраб не называл числа с потолка
Далее получаем, что чтобы получить нужные числа, похоже приходится вводить какие то бредовые условия, которые вряд ли совместимы с текущими принятыми в данной организации и другим порядком вещей.
"Нагрузить разрабов", для этого ввести стимул оплаты в зависимости от времени выполнения
Для этого надо уметь точно предсказывать срок, т.е. получается замкнутый круг.
Про то что разрабу станет выгодно сроки завышать уже написали, ну и еще вылезет много всяких проблем. Например выгодно будет брать простые задачи типа поменять надпись на условной кнопке, а сложные брать никто не захочет, т.к. там оценку дать намного сложнее и в итоге это будет бить по карману.
Для этого надо уметь точно предсказывать срок, т.е. получается замкнутый круг.
Я не понимаю, почему вы вдруг решили что нужно предсказывать срок. Размер оплаты - некая монотонно убывающая функция от времени выполнения задания.
Про то что разрабу станет выгодно сроки завышать уже написали
Почему выгодно? Выгодно остаться без премии за хорошую оценку сроков? Выгодно ждать и оттягивать до своей завышенной оценки и недополучать деньги за медленность работы?
Как вы можете понять что работа сделана медленно или быстро, если вы не можете достоверно оценить сроки?
Я может что-то не так понял, разве у вас размер оплаты это просто функция одного параметра (времени на выполнение задачи)?
Я может что-то не так понял, разве у вас размер оплаты это просто функция одного параметра (времени на выполнение задачи)?
Да
Ну и кто тогда будет делать длительные по времени задачи? Это же в чистом виде удар по своему кошельку. А если брать поправку на сложность/длительность задач, то мы возвращаемся в начало замкнутого круга)
Я не предлагаю для всех задач одну и ту же функцию использовать. Можно умножить на подходящую константу.
Вы просто поймите, что этот огород только для того, чтобы сказанные числа и оценки действительно имели значение, а не были просто спекуляциями. Может есть другие способы, просто если вы захотите вытрясти из людей некоторые числа, они будут ориентироваться на свои интересы, а не на интересы изначальной задачи оценки сроков.
Типа из серии, сегодня нет хорошего кофе, поэтому работаем "на расслабоне", оценки по срокам завышаем.
Например выгодно будет брать простые задачи типа поменять надпись на условной кнопке, а сложные брать никто не захочет, т.к. там оценку дать намного сложнее и в итоге это будет бить по карману.
За сложные задачи можно и цену увеличить, на то они и сложные. Да, согласен в этом ракурсе появляются новые проблемы. Поэтому я и не предлагал лезть в эту "дыру".
Похоже это все ведет к такой области как дизайн механизмов. Несмотря на название, это не про механику.
Разве не выполнение в соответствии с оценкой или быстрее?
Нет. Я же написал, что выплаты разрабам за быстроту работы не связаны с их оценками.
А с чем выплаты связаны? Какова функция расчета раз уж мы тут все такие программисты - нам нужна функция - что на входе и как рассчитывается результат этой функции : ))) А так - это напоминает старинный мем:
1. Быстрота
2. .....
3. PROFIT!!!111
Я вам должен всю теорию в одном комментарии был написать? Я же написал "приблизительно". Естественно все нюансы нужно учесть, чтобы просто так не получилось схитрожопить с оценками. Если у вас более изящный подход есть, огласите.
"Приблизительно ворочать мешки" и "ворочать мешки" - это две большие разницы. Именно здесь чаще всего и возникают недопонимания между заказчиками, которые же приблизительно точно знают чего хотят - и программистами, которые должны уже однозначно точно дать указания компьютеру что он должен делать : ) Впрочем, это лирика. А насчет долженствований - да я просто хотел узнать как именно должна работать ваша идея, ибо в своем приблизительном виде она выглядит для меня наивной по озвученной мной и некоторыми другими участниками нашей беседы причинам. Поэтому надо смотреть "конкретный код", а не оперировать очередными неопределенностями - такая у нас работа.
я просто хотел узнать как именно должна работать ваша идея, ибо в своем приблизительном виде она выглядит для меня наивной
Проблема 1
Как заставить разработчиков не манипулировать временем выполнения (оттягивать срок выполнения)?
Проблема 2
Как заставить разработчиков не манипулировать временем оценки?
Для этого и предложил вещи из пункта 2. Опять же могу ошибаться, но контрпримера обхода пока не увидел.
Не наказывать за ошибку в оценке? Тогда не будут и манипулировать.
Какой смысл тогда будет думать и что-то оценивать, если можно просто генерировать случайное число, все равно же никакой разницы нет.
Я не утверждаю что такой подход работать не будет, просто это может значительно ухудшить результаты.
Если вы будете наказывать людей за ошибки, это уже так себе идея, если вы будете наказывать людей за ошибки других людей, то это идея прям совсем плоха. Разработка ПО это коллективный труд и не все от одного человека зависит. Легаси, кривая архитектура, отсутствие опыта работы с конкретными либами/фреймворками/местными костылями.
Какой смысл тогда будет думать и что-то оценивать, если можно просто генерировать случайное число, все равно же никакой разницы нет.
А зачем тогда вообще думать и что-то оценивать, если тебя за неизбежную ошибку в оценке наказывают? Никакой формальной методики для оценки сроков нет. Понятно что если что-то делается в 10 раз, оценить можно, а если нет? Тут однозначно надо заложить запас)
Я вообще нигде не писал наказывать, я писал давать премию за хорошую оценку. Премия - дополнительная доплата, некоторая функция от оценки времени и реального времени выполнения задания.
В ваших словах наказывать - я понял как отсутствие премии. Премии в смысле контекста этой модели, а не той премии что к зарплате идет и распространяется на все. Плохое слово может выбрал.
Работают два программиста на одной кодовой базе по Вашей модели. Вася делает каждую очередную задачу максимально быстро и получает премию. Петя делает задачи медленнее и не получает премию. Вася молодец, а Петя нет? Выглядит так.
С другой стороны, если посмотреть, как именно Вася добивается скорости, то мы увидим что-то подобное:
Максимально дряной код, без структуры и порядка
Отсутствие документации и тестов на этот код
Что-то сломано по соседству с его кодом. Васе пофиг на совместимость - лишь бы максимально быстро сделать текущую фичу
Т.е., самый быстрый способ сделать текущую задачу всегда есть. Но на долгой дистанции он неотличим от саботажа. А тот, кто пытается поддерживать код в нормальном состоянии (Петя), получает двойную нагрузку (весь легаси + свежее говно от Васи), и за все свои усилия "награждается" лишением/уменьшением премии.
Напомнили мне историю из жизни. На одной из прошлых работ руководство решило давать премии за переработки. Фирма была по сути аутсорсом, выставляла клиентам счета на основании отработанного сотрудниками времени, то есть фирме было выгодно, чтобы сотрудники нарабатывали как можно больше часов.
В стандартном рабочем месяце примерно 160 часов. Условием максимальной премии было отработать 700+ часов за 3 месяца. Тогда помимо зарплаты человек получал премию $9000 плюс двойную часовую ставку за часы сверх стандартных 40 в неделю.
У нас нашлось несколько человек, готовых повпахивать, один товарищ даже 3 премии за год сделал.
Через год премию отменили, потому что клиенты начали разбегаться от компании, где каждый релиз сопровождается тонной багов, за починку которых пытались клиента забиллить ещё раз 😃. Причём баги чинить зачастую приходилось другой команде, так как "эффективных" обычно кидали на новые проекты, чтобы побыстрее сдать и взять новые.
Да, это жиза. Любые попытки привязать индивидуальные метрики разработчиков к фактическим метрикам процессов и баблосу кончаются катастрофой. Но, тем не менее, поток наивных экспериментаторов, готовых наступать на эти грабли раз за разом, не иссякает.
премии за переработки...
клиенты начали разбегаться от компании, где каждый релиз сопровождается тонной багов
Потому что: переработки => усталость => падение внимательности => глупейшие баги на ровном месте.
Матерь божья! Да всё просто: если у вас есть формула расчета правильных сроков - будь она хоть стохастической, хоть какой - то, собственно, вопрос манипуляций отпадает сам собой. Потому что есть ОБОСНОВАННАЯ оценка.
А если никто не может назвать и ОБОСНОВАТЬ правильность оценки срока, то все дальнейшие рассуждения - гроша выеденного не стоят по сути. Даже и оценки постфактум - фигня, потому что в процессе разработки не только злонамеренное сачкование может быть, а и масса других факторов, например, проблемы с железом, с документацией, с неизвестными дотоле багами в подключаемых сторонних библиотеках, с непреднамеренными факапами, с затягиванием сроков поставки каких-то ресурсов - схем там процессов, или данных, доступов - да тут просто прорва факторов.
И в конце концов, друзья мои, именно ТОТ СРОК, ЧТО ВЫШЕЛ ПО ФАКТУ - И ЕСТЬ РЕАЛЬНЫЙ СРОК РАЗРАБОТКИ : ) Именно в нем и "учтено" всё то, что могло произойти и произошло таки! А всё остальное - если бы, да кабы.
А с чем выплаты связаны? Какова функция расчета раз уж мы тут все такие программисты
https://habr.com/ru/articles/749206/comments/#comment_25770760
Если нужны конкретные функции - могу попробовать написать.
"вероятностная модель распределения оценок" вообще не совпадает с результирующим распределением времени затраченного на выполнение.
Да, в общем случае не совпадает. Мне следовало написать - вероятностная модель взаимного распределения оценок времени и реальных значений затраченного времени.
статистика - это когда у вас есть данные о распределении соотношения значений величны какого-то выходного параметра, и значений каких-то входных параметров. Если что это "неканоничное" определение.
Не нравится слово "статистика" - замените на "данные". Это все придирки к словам. Я понимаю, что если более строго подходить к слову "статистика" - это функция от неких собранных данных.
Так вот входные параметры - это буковки, которые составляют описание таски. Плюс текущее состояние проекта и его кода. Плюс состояние документации. Плюс опыт и знания разрабов. И вот уже это - неразрешимая проблема. Вы просто не сможете качественно классифицировать входные параметры, чтобы по ним собирать статистику значений выходных параметров.
С учетом этого всего сам разраб и оценивает. А в вышеприведенной модели всего несколько входных параметров: разраб, время его оценки и реальное время выполнения.
одна и та же задача "добавь в систему новый отчет" может занимать как 2 часа, так и 2 недели, так и 2 месяца. Средняя оценка в 2 недели - в большинстве случаев будет неверной
Нигде в своем изначальном комментарии я не употреблял словосочетание "cредняя оценка".
Тут вовсе не рассматривается вопрос стимуляции разработчиков, тут именно что вопрос - а как оценить разработку проекта более-менее приемлемо? Эта проблема не только перед заказчиком стоит, но и перед разработчиком.
Усреднение разных оценок не поможет. Разработчики все с разным опытом, да и опыт одного и того же разработчика изменяется со временем. Это раз. Второе - это то, что любая оценка даже опытнейшего разработчика строится на неопределенности - ну то есть в лучшем случае понимает это, а в худшем - занимается самообманом, который выльется в срыв озвученных сроков, что повсеместно и происходит с малоопытными, но - или, скорее - "потому и" - уверенных в своих оценках, специалистами.
Конечно, бывают проекты, в которых требования достаточно точны и даже имеется опыт их реализации - их оценивать легче и можно не перезакладываться сильно на риск, но даже в таких проектах факторы неверных толкований и вероятных изменений не отменяются и создают риск не влезть в неучитывающий их срок.
Конечно, если вы пишите из года в год примерно одно и то же на типовой платформе, плюс как-то научились контролировать грейд специалистов (обязательной сертификацией/аттестацией, например), то статистический подход еще может помочь, но это довольно узкая область разработки ПО. Подавляющее же число разработок ПО слабо походят на друг друга.
И в любом случае, это про те случаи, когда проект небольшой, по большей части состоит из знакомого по опыту функционала и требования прописаны достаточно детально, а часто - ТЗ состоит из дефиниций "хотелок", без каких-либо деталей и/или требуется "запилить" что-нибудь из разряда "как у Гугла" - только вот заказчик не понимает, что Гугл разрабатывал свою машинерию 30 лет огромными командами и сделал кучу неудачных подходов, прежде чем получил результат.
Тут вовсе не рассматривается вопрос стимуляции разработчиков, тут именно что вопрос - а как оценить разработку проекта более-менее приемлемо?
Я не утверждал что нужно стимулировать разработчиков. Просто если вы хотите получить какую то цифру, желательно имеющую значение, нужно чтобы у людей был стимул делать точную оценку и делать работу максимально быстро (а не по настроению или наличию хорошего кофе). Если эти условия убрать - вы скорее всего не получите нормальных количественных оценок или многократно ухудшите их.
Не забываем https://habr.com/ru/articles/749206/#comment_25770458
Мне кажется тут от частичной проблемы (ИНОГДА бывает так что сроки очень сильно расходятся с оценкой) сделали глобальную проблему (НИКОГДА невозможно оценить с нужной погрешностью).
По момему опыту это не так. В большинстве случаев задачи типовые и можно либо найти что-то аналогичное, либо оценить сроки сверху и снизу.
Да, 100% попадание добиться невозможно, но если условно в 90% мы укладывается в среднее, в 9% мы укладываемся в максимальную оценку сверху и в 1% случаев мы выходим за максимальной оценки сверху это НЕ СТРАШНО, так как статистически в рамках команды в большинстве спринтов мы будем выдавать необходимый результат.
Условно если мы делаем ремонт дома, мы не сможем предсказать точные сроки каждого этапа, так как всегда может оказаться, что окажется, что проводку делал кто-то с альтернативно растущими руками и на ее замену потребуется на порядок больше времени. Нам важно, что в сроки в ЦЕЛОМ не вышли за оговоренные рамки. Поэтому стоит с одной стороны разбивать на мелкие задачи, с другой стороны как можно раньше оценивать самые опасные части.
Ну да, для типовой разработки это более-менее работает - вот вы пишите типовые конфигурации 1С, к примеру, имеете штат сотрудников, чьи навыки работы с типовыми инструментами 1С экзаменуете периодически - и да, можете вполне адекватно предсказывать разработку. Но это очень далеко не всё, что происходит в разработке ПО - как раз таки подавляющее большинство - это новые предметные области с новыми подходами и новыми требованиями - и здесь, в этой обширнейшей нише расчеты сроков становятся заметно неточными, потому что нет типовых решений.
вот вы пишите типовые конфигурации 1С,
Вот я писал на Java/JavaScript последние 20 лет в крупнейших компаниях в мире (в своей рыночной нише — по для телекома, поиск отелей, вебстриминг для взрослых, предсказание онлайн рекламы, по для аудиторских компаний, банк евросоюза). И не поверите — большинство задач это решение типовых задач типовыми инструментами.
подавляющее большинство — это новые предметные области с новыми подходами и новыми требованиями
Вы так считаете? На мой взгляд, большинство задач в МИРЕ это у нас есть какие-то данные, нужно взять типовые инструменты, сделать типовую аналитику с типовым фронтов и с типовым беком, сделать интеграцию типовыми способами и т.д.
Как минимум тогда интересно - каким образом вебстриминг, например, и банковская система является типовой относительно друг друга? Вы хотите сказать, что банковские расчеты и логика - это такой вид вебстриминга?
Вы так считаете? На мой взгляд, большинство задач в МИРЕ это у нас есть
какие‑то данные, нужно взять типовые инструменты, сделать типовую
аналитику с типовым фронтов и с типовым беком, сделать интеграцию
типовыми способами и т. д.
Невероятно сильное обобщение. В принципе, все в природе из одних и тех же атомов состоит - значит ли это, что разница между камнем, положим, и человеком - невелика? : )
Невероятно сильное обобщение. В принципе, все в природе из одних и тех же атомов состоит — значит ли это, что разница между камнем, положим, и человеком — невелика
Нет, речь о другом. Представьте вы автомеханик, с одной стороны можно сказать, что существует почти бесконечное количество комбинаций разных двигателей/коробок/ходовой/прочих деталей и почти бесконечное количество поломок и т.п. C другой стороны, в реальности все похожее и относительно быстро вы изучите настолько, что в 99% случаев вы уже что-то когда-то похожее решали (особенно при десятках лет опыта).
В программировании тоже самое — очень-очень многое это типовые задачи вида сделать авторизация на сайте с такими вот правми, сделать такие вот отчеты, вот такие объекты должны сохраняться. Все строится из типовых крипичиков и единственное отличие это бизнес логика, которая тоже обычно сводиться к доволько стандартным запросам (аля построить обычный sql и на его основе типовой график).
Вы своими словами как бы отрицаете реальность: что, мол, технологии каменного века - суть всё то же самое что и современные нам, "ведь всё ж типовое". Этак вас послушать, так и никакого развития нету, а вы - легко правой пяткой настрочите нам ИИ покруче всех - а чего там, всёж те же самые битики ж туда-сюда перекладываются.
Бэкенд-фронтенд - и в продакшн!
Я этого не говорил. Я говорил, что в 99% случаев программные задачи уже много раз много кем решались. На каждого сотрудника OpenAI существует сотни и тысячи программистов, которые условно перекладывают json'ы и выводят данные пользователю на страницу.
И что с того, что задачи решались много раз кем-то, когда речь про вашу оценку? Это вы много уже раз решали все задачи? Или даже ваши коллеги по компании, которые вам подскажут?
И по-порядку:
Технологий - разных - великое число, и их становится только больше, и спрос на них постоянно растет. Обойтись json'ом и знанием SQL можно только в узкой нише. Да, есть набор технологий, которые присутствуют практическом в каждом проекте, однако это не равно тому, что именно они определяют проект и из них следуют все иные, задействуемые на проектах, технологии. Я не знаю с чем вы там работает, что у вас так славно всё выводится из очень небольшого набора технологий, хотя, вот, то же упоминание стриминга - вы что, серьезно его json'ом передавали? Я сам имел дело с видеостримингом и прекрасно знаю, что без понимания работы кодеков, без понимания строения видеоданных, без понимания специфичных протоколов передачи стрима, никакого видеостриминга не получится, и знания json и SQL тут нерелевантны. Или вам выдали готовую библиотеку с ручками, которую вы и дергали, представляя себе, что вся обработка видео - это не более, чем обращение к API? Так это другой уровень, на котором - да - всё напоминает гвозди json.
И, конечно, легко воображать себя Львом Толстым и знатоком всех технологий, но на практике - если ваша работа действительно разнообразна, а не так как я и писал - имеет более-менее типовой характер, то вы постоянно сталкиваетесь с отсутствием опыта в некоторых областях, который невозможно вывести из вашего иного опыта, ибо при всем том, что действительно в основе все те же биты, но организованы они сильно по-разному, и через это приобретают принципиально иные качества.
Про востребованность технологий я тоже не с потолка беру - сейчас чуть не каждый пятый хочет то аналитическую базу с нехилыми объемами данных, где где реляционные базы данных уже не вывозят, то нейросеть, то свой ГИС-сервис, то еще что. Причем ожидания, само-собой, на уровне качества сервисов ведущих вендоров, представляя себе, по-видимому, как раз как и вы, что сделать такую штуку - как два пальца об асфальт - оно ж "все одно и то же".
Второе - логика. Опять - логика в каком-нибудь, например, сайте - интернет-витрине, и логика в комплексной системе, которая охватывает модули работы с поставщиками, учетные системы, склады, логистику, системы мотивации продавцов, маркетинговые системы, кучу еще модулей и, наконец - собственно интернет-витрину - это две большие разницы. И эта логика диктует и выбор других технологических компонентов, других архитектур, других подходов. Но кроме этой технологической нагрузки и сама логика по сложности своей опять же нелинейно растет, ввиду множества связей между модулями - наивно полагать, что срок разработки сложной многомодульной системы - равен произведению срока разработки одного модуля на их количество, даже будь они примерно одинаково трудоемки - нет, так не выйдет, потому что модули не сами по себе будут работать, они связаны, и вы неизбежно столкнетесь и с задачей интеграции их в единую систему, с задачей управления этим сложным конгломератом - как на этапе разработки, так и в дальнейшем - при сопровождении и развитии этой системы, и, собственно, с задаче согласованной работы всей этой системы.
Так что я вполне обоснованно утверждаю, что, образно говоря, "автомобиль" - это не такая разновидность "лошади", хотя - да, обе как бы могут быть транспортом. Но по этому признаку - использования в качества транспорта - отождествлять их совершенно некорректно. А не образно говоря: ПО другому ПО - рознь. И потому, в том числе, и не существует универсальной и надежной методики расчета срока разработки ПО.
На мой взгляд, большинство задач в МИРЕ это у нас есть какие-то данные, нужно взять типовые инструменты, сделать типовую аналитику с типовым фронтов и с типовым беком, сделать интеграцию типовыми способами и т.д.
За сколько времени вы сможете написать мне CRM-систему? Создание CRM вроде как типичная задача, состоящая из типичных компонентов, разработка её выполняется в типичных средах разработки, типичными девелоперами. А значит для вас, специалиста с таким большим опытом работы, не составит труда мне сообщить, сколько же времени понадобится для написания CRM системы.
За сколько времени вы сможете написать мне CRM-систему?
Очень интересный вопрос!
Вы не уточните, что Вы понимаете под CRM-системой? Чтобы лучше понимать условия задачи. Будем считать это своеобразным пет-проектом. ;-)
Вы не уточните, что Вы понимаете под CRM-системой?
Ну типичную CRM-систему. "Вы же специалист?" (c)
Ну типичную CRM-систему. "Вы же специалист?"
Если типичную CRM систему без всяего ТЗ — за день я найду open source CRM систему и переделаю логотип.
За сколько времени вы сможете написать мне CRM-систему? Создание CRM вроде как типичная задача, состоящая из типичных компонентов, разработка её выполняется в типичных средах разработки, типичными девелоперами.
Вы путаете типичность и трудозатраты (и вообще затраты). Произвести любой автомобиль, серийную яхту или серийный самолет это тривиальная задача, которая компания их производящяя делала тысячи раз. НО себестоимость и цена там может быть очень даже не маленькая. Типично не значит бесплатно или дешево.
Если я у вас попрошу типичную стоимость и время производства серийной машины, яхты, дома или веротолета (не уточняя что именно я хочу) вы сможете мне ответить кроме от ста $ до миллиарда $?
Ну типичную CRM-систему. "Вы же специалист?" (c)
Не я здесь специалист. Но если я сделаю свою CRM-систему, то стану специалистом. Как-то так.
в 90% мы укладывается в среднее
извините, но это какое-то альтернативное среднее. Среднее обычно работает так, что половина ниже, половина выше. В случае с проектами 50% в сроки не уложились.
Ваши 90, предположу — очень похожи на "запас". Можно представить в виде гауссова распределения и попыткой средним + интервалами в несколько сигм покрыть нужный процент случаев.
извините, но это какое-то альтернативное среднее. Среднее обычно работает так, что половина ниже, половина выше.
Смотря как оценивать, точнее с какими допусками. Среднее в данном случае не среднее-арифмитическое, а попытка оценки task максимально объективно в story point'ах (без накидования максимально допустимого запаса).
Если у нас есть story point'ы (0.5, 1, 2, 3,5 и 8) и мы говорим, что 0.5 это рабочий день, 1 — 2 дня, 3 — неделя, 5 — полторы недели, 8 — весь двухнедельный спринт.
И c помощью planning poker мы распределили story point'ы по задачам. Вот если мы укладываемся в наши story point такой оценки — у нас все хорошо. Если мы не укладываемся даже в оценку сверзу — то у нас либо что-то случилось (дев. сервер лег на неделю) или мы совсем промахнулись с оценками.
P.S. Нужно понимать, что разработчики не должны постоянно работать на максимально возможной производительности, иначе они быстро "сгорят", то есть любая оценка всегда должна закладывать возможность спокойно сделать задачу с учетом отдыха/кофе брейков и т.п. Попытка "выжимать" из программистов все соки ставя все более короткие сроки это вообще не очень здоровая практика с точки зрения менеджмента (ну если не случилось реального аврала, который никак не было избежать).
Можно брать "доверительный интервал" куда вы будете попадать с 90% процентной вероятностью. Но тут есть проблемы, что либо интервал может быть довольно широкий, либо оставшиеся 10% будут улетать в "тяжелые хвосты" (условно говоря нестандартные задачи с ошибкой трудоемкости на порядок), и хоронить все остальные оценки.
В большинстве случаев задачи типовые и можно либо найти что-то аналогичное, либо оценить сроки сверху и снизу
В большинстве случаев, скорей всего, не будет достаточной экспертизы для такой оценки. Вот в соседней статье жалуются на выступления спикеров из топовых компаний на конференциях — даже они не могут сделать сравнения разных технологий. Что уж говорить про основную массу компаний/разработчиков.
А, ведь, что такое интегрирование? Это суммирование измеримых объектов. А как мы получаем измеримые объекты? Правильно! Разбиваем исходный объект на очень маленькие кусочки и аппроксимируем эти кусочки правильными (заведомо измеримыми) объектами. Всего-то и требуется: найти в программировании такие элементарные операции, которые требуют (при прочих равных) заранее известного времени выполнения. Делов-то! ;-7
Это рассуждения недавнего школьника, познавшего Силу интегрирования и теперь воображающего себе, что сейчас он и тестикулы Бога проинтегрирует : )
Всего-то и требуется: найти в программировании такие элементарные операции, которые требуют (при прочих равных) заранее известного времени выполнения. Делов-то!
Так это (декомпозиция) уже давно сделано — называется "язык(и) программирования". Только выполнить обратное действие (композицию) с вашей легкостью и с вашим результатом пока не получается.
Но это было бы возможно как коммерческий проект в какой-то нише в стиле low-code/no-code. Что в принципе сейчас и пытаются делать.
Не (очень) получается, потому, что язык прорапмирования — это не совсем та декомпозиция, которая нужна. Речь идёт о типовых задачах.
И ещё. У меня нет ни лёгкости, ни результата. Я ничего не предлагаю. Лишь констатирую некоторые факты и обстоятельства.
Хотя... было бы здорово что-то предложить дельное, а не только слова.
необъяснимый оптимизм разработчиков и заказчиков
Дело не в разработчиках или заказчиках. Люди в принципе склонны к чрезмерному оптимизму.
Если бы люди умели правильно оценивать время — никто бы не опаздывал на поезда или самолёты.
А ведь это задача всяко проще разработки ПО.
Это нормальная биологическая стратегия выживания : ) Другое дело, что при всем оптимизме, надо понимать, что твои оценки не имеют под собой достаточных оснований, и воспринимать их и работать с ними надо соответствующе, без возложение чрезмерных надежд.
А оптимизм при этом терять не надо : ) Надо всего лишь принять, что нет способа точно предсказать будущее, а если ты себя и не обманываешь этим - то открываются уже новые возможности!
Статья пустая, исключительно ради поднятия шума. Но шум удался. Это означает, что автор задел весьма громко звучащие струны в сознании отписавшихся комментаторов. Проблема действительно важная, хотя решения ни автор, ни комментаторы так и не предложили. А раз решения нет, то и струны постоянно шевелятся, монотонным гулом напоминая всем о несовершенстве мира.
Но решение, разумеется, есть. Только оно не в рамках существующей системы. Именно в этом заключается проблема, из-за которой решения всё ещё нет.
Наверх вылазят кто? Как вы думаете?
Те, кто вылез, чем достигли высот? Как вы думаете?
И когда такие особи встречаются со сложной задачей, которую за них никто не решит, то способны ли они на такой подвиг? Как вы думаете?
Ну вот поэтому задача до сих пор и не решена. И вы даже знаете её решение - надо что-то поменять на самом верху. Вы ведь так думаете?
Очень интересно, но ничего не понятно
Мелочь качество ПО в принципе не потянет, не те ресурсы. Их удел - использовать готовое. А готовое делают большие конторы. Но там свои правила, эволюционно складывавшиеся в течении столетий. В большинстве случаев эти правила поощряют простые подходы, вроде нанять эксперта, который нам всё красиво нарисует. Но эксперт не сможет изменить целеполагание. А целеполагание тоже простое - надо взять максимум с хомячков. Наиболее эффективны в этом плане (после насильственного отъёма) стратегии на основе манипуляции эмоциями. Вот в эту сторону и совершенствуется мир корпораций. Ну а сложные системы, к которым относится и набор задач по разработке качественного ПО, остаются в тени, ведь зарабатывать через качество (включая составляющую, ответственную за соблюдение сроков) намного менее прибыльно в сравнении с альтернативами.
В итоге мир пришёл к "приемлемому" качеству, то есть доступному при небольших затратах на обеспечение оного. Так выгоднее всего.
И вторая часть - совершенствоваться в сторону "soft skills" бывает важно для топов. А на "hard skills" в области ПО ни времени, ни желания не остаётся. Поэтому сами они в принципе не смогут ничего улучшить, даже если бы захотели. Могут позвать экспертов, но те ведь обучены на массовом рынке, где востребованы решения узких прикладных задач, а не изменение парадигмы взаимодействия людей в обществе.
Так что рынок не хочет улучшений. А альтернатив рынку в мире, по сути, нет. То есть без перемен именно наверху ничего нам не светит.
Это не неразрешимая проблема разработки — это неразрешимая проблема жизни: как успеть сделать хорошо и за хорошую оплату, если требуют очень быстро, качественно и недорого.
Эту проблему, очевидно, решает готовая библиотека компонентов. Но никто не готов заниматься её созданием. Это и есть настоящая неразрешимая проблема.
Даже если представить, что такая библиотека существует, то она будет настолько объемная и сложная, что вопрос сложности все равно останется. Ну и вопрос — а развиваться она будет? Что там будет с консистентностью, обратной совместимостью, межплатформенной совместимостью, багами и т.д.? Сложность никуда не уйдет, хотя может быть несколько и уменьшится.
Зачем нужно развитие того, что является по построению достаточно полным?
Обратная совместимость чего с чем?
Межплатформенная совместимость? Этот вопрос исходит из того, что библиотека делается на неоктором существующем языке программирования, в то время, как наука чётко предписывает создание специализированного языка под решение каждой конкретной задачи, и уже трансляцию кода на этом языке к од целевой машины.
Зачем нужно развитие того, что является по построению достаточно полным?
В смысле полным? Мир остановился в развитии, нет новых технологий, моделей поведения — так что ли? Ведь это новое будет требовать и новых программных решений.
наука чётко предписывает создание специализированного языка под решение каждой конкретной задачи
Это какая такая наука? И это как получается — у вас будут тысячи и миллионы языков?
Мир остановился в развитии, нет новых технологий, моделей поведения — так что ли? Ведь это новое будет требовать и новых программных решений.
Простите, это, просто, моё собственное восприятие и отношение изменилось. Раньше я был ярый сторонник прогресса. Видел этот прогресс во всём. Теперь всё иначе. Теперь я вижу, что перед бизнесом (скажем так) всегда стояли (и будут стоять) одни и те же задачи. Новизна в чём? Хорошо, раньше был только текстовый интерфейс. (Ну, был распространён. Графический тоже существовал давно.) Были одни ОС-мы, оболочки, системы программирования, сами языки программирования. Теперь у нас только графический интерфейс. Не было сетей. Да! Они появились. Распределённые вычисления, клиент/сервер, трёхзвенная архитектура, BDE, OLE DB, ADO... А теперь ещё нас настиг блокчейн, мобильная разработка (привет старым-добрым мейнфремам и подключенным к нему тонким клиентам!). Да ещё и ИИ подкатил. Подкатил, так подкатил! (с)
Мы с Вами сильно расходимся в том, на что обращаем внимание. Вы видите больше динамическую составляющую, на процесс, на прогресс. Я же пытаюсь найти нечто постоянное в этом бурно меняющемся мире, некий инвариант, самосохраняющуюся структуру. Когда новое оказывается хорошо забытым старым. Например.
Мне никто ещё не ответил на вопрос, зачем программисты тратили множество человеко-часов на создание разного рода библиотек. И, кстати, продолжают создавать! Я смутно вспоминаю ещё библиотеку Turbo Professional (которая быстро на глазах трансформировалась в Object Professional) времён Turbo Pascal 5.0 и 5.5. Потом пришла библиотека Turbo Vision. Думаю, до сих пор можно найти программы, написанные на ней. Потом пришёл графический интерфейс, а с ним и OWL. И где теперь OWL? Довольно заметный след оставила библиотека VCL, но и этому пришло на смену DOTNET, ASP... А сейчас? Постоянно предлагаются новые программные решения. Постоянно появляются новые названия и аббревиатуры. Но задачи-то прежние! Как нужна была складская/торговая система, так и будет нужна. библиотеки, образовательные ресурсы, банковские приложения.
В чем же развитие? Почему нельзя один раз написать код и потом его всё время использовать? Кто-нибудь объяснит? Зачем писать код, который потом будет выкинут, потому что найдётся, видать, новое программное решение? А в чём новизна данного решения? В новых обстоятельствах и действующих лицах (включая web)? Почему, вообще, приходится что-то переписывать? Ведь главный источник затягивания любых сроков — это лавинообразное "наплывания" нового кода, который всё-время приходится писать. Можно ли действовать иначе, вот в чём вопрос.
Это какая такая наука? И это как получается — у вас будут тысячи и миллионы языков?
На западе эту науку называют Computer Science. И в рамках этой науки давно-давно установлено, что разработка приложений заключается в создании специализированного языка. Раньше под каждую задачу создавался свой язык. Для алгоритмического обеспечения — Алгол и подобные ему языки, для символьных вычислений — Рефал, для реализации математического обеспечения — Фортран. При этом, возникали разновидности, которые позволяли более эффективно решать частные задачи: Модула и Ада — модульность. Потом, ещё есть языки функционального программирования, в основу которых кладуться определённые идеи и понятия — понятия списка (Лисп), понятия рекурсивной функции (Форт), понятия категории (Хаскел)...
Сегодня мы видим засилие языков программирования общего назначения, в которых вся мощь переносится на библиотеки, предназначенные для решения частных задач. А Вы можете представить специализированные языки, созданные, например, отдельно для представления и управления пользовательским интерфейсом? Необходимость в таких языках побуждает вводить новые элементы в существующие языки, что не только утяжеляет сами языки (их компиляторы), но и затрудняет их изучение. И всё это — вместо того, чтобы создавать новые языки. В результате, всё-таки появляются новые технологические решения, но это уже задним числом. Современное программное обеспечение — это лоскутное одеяло.
Почему нужны различные языки программирования? Это можно ещё объяснить и так. Допустим, мы хотим создать систему. В обычной ситуации мы берём какой-то язык программирования и создаём на нём весь необходимый код. Вот он лежит в виде набора текстовых файлов, достаточно запустить транслятор, и приложение готово. А теперь добавьте сюда один промежуточный язык программирования — язык, на котором Вы описываете систему. Так вот, это описание — основа основ — "скармливается" транслятору на код целевой машины. Таких трансляторов может быть много — под разные вычислительные архитектуры, разные практические нужды. Это можно сравнить со схемой базы данных: на концептуальном уровне у вас имеются определённые объекты и определённые отношения между ними, на логическом уровне возникают таблицы и уже отношения между таблицами, но уже на физическом уровне определяется, как именно реализуется то или иное отношение. Так и при разработке системы, Вы не обязаны кодировать систему непосредственно в конечном виде. Например, вы знаете, что здесь должна быть переменная, но не знаете какая (какого типа). Вы описываете алгоритм обработки в общем виде. В реальности, конечно, Вы будете сразу делать всё в конечном виде. Но, зафиксировав однажды, тип переменной, Вы обречётся себя на большую возню с собственным кодом в случае, если тип переменной поменяется. В случае же разделения языков, вы просто поменяете какие-то опции при трансляции с кода языка верхнего уровня на язык нижнего уровня.
Заметим, что программистские конторы сами создают такое разделение немного искусственным образом, когда пишут внутренние библиотеки, позволяющие генерировать пользовательский интерфейс на лету, разрабатывая специализированный язык метаданных.
Другое дело — вопрос надёжности. Всё-таки, у таких подходов может что-то пойти не туда, "баг" на высоком уровне нанесёт больший урон, чем "баг" на низком уровне, "баг" в слое дополнительной абстракции попросту не даст программе сработать. Так что по старинке предпочитают не заморачиваться с абстракциями и "хардкорят" всё, что только можно. Это понять можно. Но за всё приходится платить. В том числе, и скоростью и непредсказуемостью разработки. Конечно, для создания дополнительного слоя абстракций (например, языка программирования) нужно время. Это правда. Но тут, как говориться, нужны реальные примеры: кто и в какой канторе по каком пути пошёл и к каким результатам пришёл. Однако, история об этом умалчивает. Я очень хотел бы послушать такие истории.
Почему нельзя один раз написать код и потом его всё время использовать?
Если бы весь код должен был быть открытым и стандартизованым (по ISO например) то так бы и было. Но я скорее поверю в то, что вся наша жизнь — это наш сон, что все это нам только снится, чем в такую рациональность поведения.
Скорей всего, проблемы тут не технические, а организационно-социально-экономические. А они, как известно, практически не решаемы.
Раньше под каждую задачу создавался свой язык
Да, теперь понял.
Современное программное обеспечение — это лоскутное одеяло
Ну да, все коммерческое, все должно приносить прибыль, а про остальное думать некогда. Поэтому прогресс — это неожиданный побочный продукт жадности людей, а вовсе не результат системных действий перфекционистов.
А теперь добавьте сюда один промежуточный язык программирования — язык, на котором Вы описываете систему
Сейчас работает "гибкий подход" к проектированию технических инструментов, вы же ратуете за более централизованный и системный. Плюсы и минусы есть у каждого из них, но я все таки больше сторонник гибких методов — они больше подходят к жизненным реалиям, хотя в итоге суммарно и обходятся дороже.
Интересно было узнать про такой взгляд на эту проблему!
Неразрешимые проблемы разработки