Комментарии 17
В левом столбце хорошие бизнес-метрики, но их проблема в том, что они измеряют объем выработки вместо бизнес-ценности, на которую в первую очередь опирается заказчик
сть хорошая новость – существует адекватная методология измерения DORA (DevOps Research and Assessment). Вместо контроля за количественными действиями рук программиста, она предлагает оценивать здоровье процесса через четыре показателя: частота деплоя, время докатки изменений (Lead Time), частоту отказов при деплое и время восстановления системы. Эти метрики в совокупности дают представление о конечной способности системы поставлять ценность.
Ну постройте аналогичную количественным показателям табличку, что будут осознанно и не осознано делать люди чтоб выполнить КПИ по таким метрикам, что там будет?
Наверно тут самая важная оговорка "КПИ по таким метрикам" - по метрикам базово не должно быть КПИ, иначе они всегда будут искажаться, какие бы метрики мы бы не сделали
В Японии выход нашли уже очень давно: каждое инженерное подразделение должно в месяц выдавать по патенту - на продукт, который имеет коммерческую ценность. Нет патента - нет премии в конце месяца; то есть вынуждают всех, кто “сидит и думает (код пишет, чертежи делает, расчёты, аналитику)” - думать целенаправленно. У “Тойоты” - неплохо получилось. Чтобы возле каждого инженера по надсмотрщику не ставить - такой системы достаточно.
В логике работы завода есть предсказуемость – через заданные промежутки времени по конвейеру проходит готовое изделие, и если мы хотим увеличить выпуск продукции на определенное количество, достаточно добавить ещё смен или поставить новые станки
Это и есть основное содержание работы многочисленных программистов. К этому всегда стремится руководство — как можно полнее формализовать работу и поместить её в жёсткое прокрустово ложе разнообразных "метрик".
Работа айтишника серьезно отличается от конвейерности, и создание кода (основного продукта) как таковое занимает далеко не основную часть времени кодера.
На самом деле, можно привести и другие примеры отличий от конвейерности в других областях. И это не только научная работа, которая хорошо "ложится" под содержание статьи. Даже если взять работу на складе, то мы увидим, например, как у человека, осуществляющего раскладку (выкладку) товара, есть своя конвейерная часть ("пикание" товаров), но есть и своя творческая часть (наведение порядка на полках). К сожалению, платят только за "пики", а за порядок не платят, хотя именно порядок на полках и есть основная цель работы даркстора (ибо только при соблюдении порядка на полках можно обеспечивать высокую скорость выполнения заказов). В научной работе "пиками" являются публикации, и тут происходит своя борьба за "пики".
Плохая метрика почти всегда порождает не рост качества, а рост имитации.
Например, пробовал бы кто-нибудь (в даркосторе) задастся вопросом: почему медленно собираются заказы, как повысить скорость сборки? Обычно этот вопрос решается предельно просто: ищутся особо бегучие сотрудники. Выигрываются секунды. Сборщики так и гоняются между товарами. А где тратится основное время? На перемещении из точки "А" в точку "Б". Как сделать так, чтобы этого перемещения не было? Создать отделы, чтобы каждый сотрудник сидел в своей комнате. Комната — это отдел магазина. Сборщик должен сидеть за столом и собирать корзину. Приходит пачка заказов, и программа раскидывает эти заказы по отделам. В отделе сидит свой сотрудник, который выкладывает товар в коридор. В коридоре снуют курьеры. То есть — повышение производительности заключается в том, что над заказом работает несколько человек одновременно. При этом, минимизируются перемещения. Но тогда надо и платить повремённую оплату, а "пики" рассматривать как дополнительный заработок.
Желание повысить эффективность работы закономерно и понятно всем, однако в ИТ один из лучших способов сохранить темп развития проекта в долгосрочной перспективе – это признать, что качественная разработка требует времени на раздумья, которое невозможно сократить никакими методами промышленного принуждения.
Вот и получается, что на дарксторе время раздумья — это время, когда я навожу порядок на полке. Попробуйте это время как-то пронормировать! Порядок можно навести и предъявить, но тогда нужно и акт приёмки оформлять: мол, порядок наведён — оценка такая-то. И платить соответствующе.
А, уж, про научную работу я и вовсе молчу. Можно сказать, что человек постоянно о чём-то думает. И отдохнуть/отвлечься тоже нужно, чтобы качественно думать. А это не распорядок дня с 9 до 18.
Нормально Вы машиностроение опустили с Вашим этим - если 10 Токарей точут 10 болтов то... Во-первых сравнивать Инженерный труд с трудом специалиста немножко некорректно. Во-вторых Болты так-то автоматы делают. А вот автоматы делают инженеры конструкторы. И уж Поверьте, труд рядового инженера-конструктора сложнее чем труд рядового программиста.
Работал 5 лет после университета инженером-конструктором мостов и эстакад (их пролетных строений, если точнее).
Со временем адаптации вся работа свелась к построению модели в китайском ПО, которое прикладывало нагрузку и рассчитывало усилия. После этого усилия отправлялись в табличку excel, которая делала проверку по СНИП по предельным состояниям. После этого в обычном автокаде выполнялись чертежи параллельно с просмотром сериала (смотрел даже на английском, когнитивная нагрузка при черчении была минимальная). Конечно это все требует образования и некоторого желания для ускорения расчетов и прочего, но кроме зарплаты в этом для меня не было ничего сложного. Тем более сечение балок в итоге все равно принималось "как в том проекте, что уже стоит" для душевного спокойствия ГИПа.
После 8 лет работы разработчиком мобильных приложений могу сказать, что эта работа гораздо ебанутее и сложнее для мозга: постоянная борьба с когнитивной-сложностью и менеджерами-долбоебами, а сейчас последние сошли с ума по ИИ и хотят, чтобы ленивые разработчики стали уже хоть что-то делать.
Не верю я вашему утверждению про рядового конструктора.
Наверное тоже не очень корректно сравнивать работу конструктора на большом проекте с мобильными приложениями в ИТ. Тогда уже давайте сравнивать крупный инженерный проект с разработкой крупной системы, где зарегулировано все и на каждый чих есть инструкция. Например, банковская система, крупные медицинские системы, федеральные проекты.
А разработку небольшого приложения корректнее сравнивать с гаражом, где инженерная мысль имеет возможность для полёта.
Вы правы, сравнивать нужно сравнимое.
Мой комментарий был к фразе "труд рядового инженера-конструктора сложнее чем труд рядового программиста", коими я себя и считаю. Если сравнивать посредственность с посредственностью, то IT выжигает сильнее. Впрочем, сейчас жизнь стала в целом сложнее, чем в далеком 2012, и вероятно у инженеров все стало тоже куда горше.
Согласен что с рядовым конструктором сравнивать некорректно, вну если только с джуном зелёным.
А вот с ведущим или руководителем группы/направления - вполне. У меня в подчинении КБ на 25 человек, занимаемся реверс-инжинирингом. И это не просто копирование изделия, так как зачастую работаем с изношенными деталями, разными материалами, где тоже надо понять "контекст" изделия и почему это было сделано именно так в оригинале. Потом технологи должны отработать сам процесс изготовления, найти подходящее производство и далее по цепочке.
Ого, предыдущий комментарий 9 лет назад, зашел в профиль почитать истории про будни начальника в КБ с 25 сотрудниками в подчинении, но там ничего
Как-то колдунья наложила заклятье на молодого человека, не дававшее ему говорить больше 1 слова в год. Он молчал 9 лет и сказал: "Согласен что программиста с рядовым конструктором сравнивать некорректно"
Попытки померить любой интеллектуальный труд и тем более связанный с исследованиями и/или творчеством на манер количества выложенных каменщиком кирпичей всегда приводят к провалу. Иначе и не может быть.
Но ещё есть такой фактор, который я уже минимум 20 лет вижу в разных местах. Это такое уродливое явление как т.н. "менеджер проектов", который сам слабо представляет как именно устроен проект и/или технология, но натужно пытается этим руководить.
Сейчас даже бывает, что и вообще сажают на руководство тех.проектами управленцев по общим вопросам - т.н. эФФективных мэ-э-энеджеров - т.е. профессионально ничего вообще не знающих болванов-недоучек с экономическим а то и с гуманитарным образованием.
И особенно это характерно для России, где пристроить своего человека или родственника всегда важнее конечного результата (тут есть с чем сравнить, поскольку долгое время работал в сотрудничестве с европейскими компаниями).
IMHO Разумный подход для правильного развития проекта - это изначально грамотный подбор персонала и правильная его стимуляция (где-то деньги, где-то интересные задачи, где-то соревновательный подход).
Тут можно только дополнить это ещё и тем, что реальная боль начинается тогда, когда менеджеры не могут понять и структурировать все хотелки клиентов, и всё это ещё и вытекает в плохой ТЗ, и всегда это вытекает в сорванные дедлайны и цепочку недовольства, где сначала недовольны разработчики, потом клиент с менеджерами
структурировать все хотелки клиентов,
А что мешает самому сформулировать "все хотелки клиентов"? Что такого хотят клиенты, чего нельзя предусмотреть? Чего такого принципиально нового они предлагают, чего не предлагалось сделать раньше?
А ещё крайне интересно посмотреть, что получится, если взять готовую систему, попробовать написать для этой готовой системы ТЗ и представить вариант реализации системы (по шагам). Наверняка выяснится, что большую часть "хотелок" можно было "придумать" заранее, что большая часть реально пределеанной работы можно было не делать, и что работать можно было не 7/24, а в совершенно свободном темпе.
Для менеджеров это слишком сложно и не наглядно. У них "даёшь!" Это вот то самое. Пятелетку за три года! И так далее.
ИТ вам не завод: почему на разработку продукта всегда нужно «слишком много» времени