напрягаетесь ли вы на работе

[Flash-04]

Я тоже думал что такого не увижу, однако прибежал этот единорог. Теперь новое начальство требует список того, что можно пощупать руками, success criteria.

[Helmsman]

У нас тоже требует, но почему-то не находится. Иногда пытаются спустить какие-то мерки сверху, но оно никак не работает. Вот мне и интересно, кому удалось измерить.

[vdfs]

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

[Херовимчик]

В зависимости от области применения, мерками могут быть:
- клиентская база
- сокращение расходов
- увеличение прибыли
- перфоманс

Как вообще можно что-то делать, не знаю конечную цель? Таски ради тасков?

[mikeG]

Как вообще можно что-то делать, не знаю конечную цель? Таски ради тасков?

Типичный программист фиксит баги в коде 20 летней давности и в очередной раз переписывает UI к нему на новомодный фреймворк.
Разве у него есть какая-то конечная цель?

[Херовимчик]

Как вообще можно что-то делать, не знаю конечную цель? Таски ради тасков?

Типичный программист фиксит баги в коде 20 летней давности и в очередной раз переписывает UI к нему на новомодный фреймворк.
Разве у него есть какая-то конечная цель?

Вычищение багов и рефакторинг —-> customer satisfaction, перформанс, сокращение расходов (на поддержку и будущую разработку)

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

[null]

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

это уже ефрейтор, как минимум

[Helmsman]

В зависимости от области применения, мерками могут быть:
- клиентская база
- сокращение расходов
- увеличение прибыли

С такими мерками всех C*O уволить придётся. Не говоря о том, что это above pay grade простого погромиста.

- перфоманс

Как именно его измерить?

[Херовимчик]

В зависимости от области применения, мерками могут быть:
- клиентская база
- сокращение расходов
- увеличение прибыли

С такими мерками всех C*O уволить придётся. Не говоря о том, что это above pay grade простого погромиста.

- перфоманс

Как именно его измерить?

Я не знаю что вы понимание под простыми/рядовыми программистами. Тут на форуме куда не плюнь, одни сеньоры и принципалы
Перфоманс (в моем домене) измеряется временем выполнения задач. У кого-то это может быть устойчивость системы под нагрузкой

[Helmsman]

Ну я типа тоже lead, но ни один из ваших критериев от моей работы не зависит. Нет, накосячить на несколько десятков миллионов, конечно, могу, при желании, но пока как-то обходилось Для этого есть другие специалисты.
Перфоманс системы (я сначала про другой подумал) измерить можно, но улучшать его до бесконечности никто не будет. В SLA уложились - все довольны, разве что узкие места раз в года 3-4 подправят по совету DBA. Так что тоже так себе мерка.

[Херовимчик]

Ну я типа тоже lead, но ни один из ваших критериев от моей работы не зависит. Нет, накосячить на несколько десятков миллионов, конечно, могу, при желании, но пока как-то обходилось Для этого есть другие специалисты.
Перфоманс системы (я сначала про другой подумал) измерить можно, но улучшать его до бесконечности никто не будет. В SLA уложились - все довольны, разве что узкие места раз в года 3-4 подправят по совету DBA. Так что тоже так себе мерка.

А что вы там тогда лидите?

[Helmsman]

Я по технической части.

[vdfs]

Вычищение багов и рефакторинг —-> customer satisfaction, перформанс, сокращение расходов (на поддержку и будущую разработку)

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

Зачем? Зачем об этом начинать задумываться, и кто за это заплатит, если я увеличу количество тасков, которые я двигаю в Jira за спринт, улучшу перфоманс, сокращу расходы, и разведу прочую бурную активность?

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

Всё чего я добьюсь, это осложню себе жизнь. Сломаю себе WLB и буду переносить стресс на семью и личную жизнь. Плюс моя команда меня возненавидит, что я мешаю им жить (и правильно сделает). Оно мне надо?

Ваши амазонские / стартапские принципы не работают везде. Неприменимы к корпам, как минимум. Вон в соседней теме человек не хочет работать 8 часов. И я не хочу, ибо нахрена оно мне, когда я могу работать 2-4 и жить в свое удовольствие. Жизнь коротка, и поверьте, есть вещи поинтереснее, чем вкалывать за компьютером и заниматься отцитированной херней.

[MacArrow]

Вычищение багов и рефакторинг —-> customer satisfaction, перформанс, сокращение расходов (на поддержку и будущую разработку)

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

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

[Херовимчик]

(К амазону я никакого отношения не имею, впрочем как и к стартапам)

Вопрос был о метриках работы программиста. Все такси, выдаваемые этому программисту, вписываются в одну из озвученных категорий. Можно просто делать эти такси. Можно подумать/выяснить к какой категории конкретный таск относиться и приоритезировать наиболее выгодные (тот нелюбимый всеми импакт). Без увеличения часов работы, набираниях доп обязательств, порчи настроения и WLB

[Komissar]

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

я такси вызываю, я не даю их программистам.

[vdfs]

(К амазону я никакого отношения не имею, впрочем как и к стартапам)

Вопрос был о метриках работы программиста. Все такси, выдаваемые этому программисту, вписываются в одну из озвученных категорий. Можно просто делать эти такси. Можно подумать/выяснить к какой категории конкретный таск относиться и приоритезировать наиболее выгодные (тот нелюбимый всеми импакт). Без увеличения часов работы, набираниях доп обязательств, порчи настроения и WLB

Упс. Я почему-то думал Вы в Амазоне.

А вы прямо можете делать любые таски, какие хотите, и менять порядок, как считаете нужным?

Обычно верхнеуровневые задачи спускаются сверху (типа интегрировать систему XX с YY), потом вся команда их дробит на небольшие, демонстрируемые куски, и кидает в бэклог. Потом приоритезирует и планирует вместе с Product Owner / Analyst соответственно.

То есть как бы у нас нет возможности после того, как приоритеты расставлены, городить отсебятину и менять порядок запланированных работ. У нас была возможность сказать своё слово на этапе планирования. А к моменту взятия таска всё, поезд ушел, бери сверху что есть в активном спринте. Должна быть серьезная причина, чтобы че-то менять после планирования.

Вообще это хлеб Product Owner, определять наиболее выгодные куски функционала для бизнеса и ставить их вперёд. Наше дело помочь понять, какой кусок сколько труда и времени потребует. Разбить технические части. Помочь не пропустить что-то. Показать, почему тот или иной кусок важнее с технической точки зрения, и как повлияет на функционал.

А если программеров допускать приоритеты менять без надзора тех, кто понимает бизнес, то это будет цирк на колесиках.

[Херовимчик]

А вы прямо можете делать любые таски, какие хотите, и менять порядок, как считаете нужным?

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

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

[Бубновый Валет]

security особенно хорошо измерять метриками. Ты почему наш блог перетащил с blog.kontora.com, на blog.kontora.io ? Для какой такой безопасности? Как это могут взломать, никто ещё не взломал! Ты вообще за что деньги получаешь, что-то измерить ничего нельзя. Баги закрываешь, а взломов нет!

[nyekimov]

У нас мобильных разработчиков measurable results прямой - это количество application crashes. Даже в какой то момент слоган был - 0 defects in production is our goal.
У нас ставить такие цели и достигать вполне получается. Дальше идут цели по охвату рынка, то есть модуль может существовать, пока клиенты пользуются, процент жалоб не высок и пользовательская база растёт. Чтобы росла, надо добавлять новые фичи, чем мы тоже занимаемся. Какие то из них приносят Реальные деньги, другие снижают нагрузку на кол центры и поднимают общий престиж компании.
Ну и ещё когда делаем фичи, у нас работа сайзится в стори поинтс, я так и не разобрался, играют ли это большую роль, ходит легенда, что бюджет команд исходит из этих самых стори поинтс. Я хз честно говоря, в общем начальство выручаешь с фичами в срок и отсутствии багов или с чисткой багов за кем то, дают премию. Если чувак не тянет, то начинают считать стори поинтс и выставляют неуд.

[NtNet]

В зависимости от области применения, мерками могут быть:
- клиентская база
- сокращение расходов
- увеличение прибыли
- перфоманс

Как вообще можно что-то делать, не знаю конечную цель? Таски ради тасков?

Вот кстати да!
У меня бывает иногда (к счастью редко) когда выясняется что это были таски ради тасков. Борюсь с этим и стараюсь в такие компании не идти или уходить оттуда.
Слышала такое утверждение что настоящий программист любит сам процесс написания кода. Т е - конечная цель не слишком важна

Так вот - это не я вообще.
Вот это вот - сам процесс, лишь бы посложнее или наоборот попроще, разными способами меня не слишком беспокоит. (Могу конечео поиграться) но именно использую кодирование и свои знания именно как ПРИКЛАДНОЕ - к конечной цели (создание автоматизации или базы данных)

И это "таски ради тасков" является серьёзным concern для меня чтобы задумываться о получении другой профессии (мб позже ближе к пенсии)

[NtNet]

А вы прямо можете делать любые таски, какие хотите, и менять порядок, как считаете нужным?

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

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

Я обычный программист с небольшим опытом пока. И тоже примерно так ..
Не так как пишут тут остальные

Есть клиенты внутренние которые приходят и просят что-то наваять
Базу или форму ввода данных или автоматизацию или код с несколькими разными визуализациями

Директор ит конечно рекомендует что делать 1м что 2м
Но вобщем и целом задачи только мои и решаю сама.

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

А так работаю сама. Отчитываюсь раз в неделю.

Но это не mobile apps development
А базы данных developer

[xrundel]

Самое правильно оценивать работу так

1. Теория: Запилить фичу которая поможет сейлам лучше продавать продукт для вот таких клиентов. <Ссылка на исследование, цыфры>. Ожидаемый доп. доход за год: $10М.

2. Цена: 200 часов работы пограмистов, 50 QA, 20 дизайнера, 20 продукта. Итого: $100К

3. Реальность: Аналитик обосрался с расчётами, пограмист обосрался с оценкой, а вот дизайнер всё сделал как нужно. Сделали фичу за $200К, заработали $500К

4. Действие: Уволить аналитика, дать под хвост пограмисту а вот дизайнеру бонус.

[valchkou]

Самое правильно оценивать работу так

1. Теория: Запилить фичу которая поможет сейлам лучше продавать продукт для вот таких клиентов. <Ссылка на исследование, цыфры>. Ожидаемый доп. доход за год: $10М.

2. Цена: 200 часов работы пограмистов, 50 QA, 20 дизайнера, 20 продукта. Итого: $100К

3. Реальность: Аналитик обосрался с расчётами, пограмист обосрался с оценкой, а вот дизайнер всё сделал как нужно. Сделали фичу за $200К, заработали $500К

4. Действие: Уволить аналитика, дать под хвост пограмисту а вот дизайнеру бонус.

не понял, а рабочий функционал то кто сделал? дизайнер?
За эстимейт фитч такого уровня отвечает директор, випи, СТО или кто там у вас, программист просто делает и он ее сделал - дать бонус.
А кто нанимал аналитика такого? может ему дать под хвост?

[Mmodel]

Уволить аналитика, дать под хвост пограмисту

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