1. Нет. Скорее «Без ТЗ результат ХЗ, с ТЗ результат говно». ХЗ дает надежду.
2. Да. Пете надо добавить чуть-чуть — делать свои решения, которые лучше предложенных. Или хотя бы предлагать.
3. Да, это само собой. В публикации предполагается, что программист толковый, и сразу это понимает, без доп.исследований. Но нас в контексте публикации интересует польза для бизнеса, а не для пользователя.
4. Нет. Бизнес — это люди. Собственникам бизнеса очень не хватает честности и правды от подчиненных. Как в мультике «Вовка в тридевятом царстве», где двое из ларца, одинаковых с лица.
5. Нет. Это программисту решать. «Я — программист» — это не приговор, и не конечная точка пути. Она вполне может быть начальной. Каждый сам решает.
6. Нет и Да. Зависит от выбранной вами зоны ответственности. Если вы работаете от задачи собственника, то такие отмазки не прокатят, а потому и проблем таких не возникнет.
7. Ни в коем случае.
А можешь вот в этой конкретной форме сделать чтобы Ctrl+A выделяла не все элементы, а только текущий узел и подузлы?
Конкретно эта доработка выглядит полезной. Только я бы сделал не Ctrl+A, а любое другое сочетание клавиш, не используемое виндой.
Но с точки зрения бизнеса это — суррогат. Никакой пользы не будет.
На первый взгляд кажется, что сэкономится время пользователей — да, сэкономится, но они, по закону Паркинсона, просто станут работать медленнее.
В публикации речь о суррогатах применительно к бизнесу, т.е. польза ожидается для бизнеса, а ее нет. Рассматривается влияние не программирования (как физической реализации решения), а влияние выбора решения.
Если применительно к программированию, то нужно понимать, ради кого делается программирование. Цепочка получается короче — пользователю нужно одно, программист делает другое. Цели бизнеса вообще не рассматриваем — вполне вероятно, что то, что нужно пользователю, не имеет ценности для бизнеса. Если при этом оно еще и реализовано коряво, то совсем плохо. А может, и не плохо — какая разница, хорошо или плохо сделано то, что никому не нужно?
Например, программист создает и запускает внутренний корпоративный портал для компании, состоящей из 5 человек.
Или оптимизирует код корпоративной информационной системы, который используется раз в год для формирования фин.результатов, снижая время исполнения с 10 минут до 1 минуты.
Или подключает к сайту компании, работающей только по гос.заказу, систему общения с пользователями.
Вот классическая схема поэтапного «суррогатирования»:
Сорян, не заметил, что вы про систему управления, а не про саму ГЭС.
Если авария произошла именно из-за системы управления, то — да, это суррогат.
Просили систему, которая защитит от аварии, получили систему, которая не защитила.
Суррогат или нет — определяется целями потребителя.
В вашем примере цели мне, увы, не известны.
Вот есть такая система — JIRA. Сама по себе она не плохая, не хорошая. Не суррогат и не то, что нужно.
Если ее вручить дворнику для повышения его эффективности, то JIRA станет суррогатом.
Потому что «нафига козе баян».
Не совсем так. Речи о качестве кода здесь не идет, только о том, нужен ли продукт бизнесу.
Программист и его код в данной публикации — черный ящик, который либо делает продукт, либо не делает его.
Здесь имелся в виду суррогат не ожидаемый, а подсунутый :)
Покупал как-то минералку на вокзале, оказалась вода с содой. Вот такой суррогат.
Или, из бизнеса — покупаем автоматизацию бизнеса с целью сокращения затрат, получаем повышение затрат, расширение бухгалтерии и штат программистов в придачу.
вы позиционируете себя борцом с системным управленческим бардаком <...>, но играете уже по их правилам
не совсем. Я, скорее, экспериментирую и пробую разные варианты — от следования их правилам, до их полного разрушения. Иногда, ради эксперимента, делаю вид, что я такой же, как они. Это как игра. В публикации отражены 4 состояния, через которые я проходил в этой игре — сопротивляться, работать за них, возглавить их, договориться с ними.
Лично мое мнение — ради жизненного опыта надо иногда поучаствовать в подковерных играх. Не настаиваю. Это увлекательно, если границы не переходить.
Для меня первое правило разработки — делать так, чтобы потом не переделывать, т.к. обычно переделывать времени нет.
У меня почти так же, я предпочитаю создавать и пользоваться абстрактными настраиваемыми инструментами, чтобы делать с их помощью быстрое прототипирование. Там обычно и кода-то нет, мышкой все натыкивается, или живет в БД как временный код и запросы.
Здесь речь не о плохом коде, а о бессмысленных с точки зрения изменениях в информационной системе. Т.к. качество работы программиста, качество исполнения не рассматривается вообще.
Это не значит, что качество не важно. Просто не является предметом рассмотрения данной публикации.
Да, своей цитатой я выразил согласие с тем, что вы пишете.
Не стоит привязывать систему мотивации к показателям решения задач программистами, иначе будет так, как вы описали в комментарии.
Например, привязка системы мотивации к объемам выполненных задач в спринте может дать лазейку для внешних паразитов – человека станет стремиться не к результату, а к избеганию чувства вины за низкий KPI (сами понимаете, перед кем чувство вины).
Мой опыт говорит, что так делать не стоит. Подробнее писал здесь, в разделе Scrum.
За время работы над эффективностью лично у меня сложилось мнение, что ключевой мотиватор, который заставляет людей работать быстрее и лучше — их собственное стремление к развитию, повышению компетенций и личному успеху.
Отдельной строкой выделяется компетенция «работать эффективно» — это ведь не чисто технический навык. Но является конкурентным преимуществом.
Буду признателен за вопросы — нужно знать, о чем написать в первую очередь, а то бэклог публикаций большой.
Тема повышения эффективности и скорости разработки интересна?
Это разные вещи — работа над своей эффективностью и работа над эффективностью команды. Свою можно повышать молча. Чужую молча не получится.
Эффективность падавана не повышается сама собой, это результат наших совместных усилий, экспериментов и изменений в процессе работы.
На оси Y — сумма баллов (story point) выполненных в спринте работ.
Обратите внимание — фраза «работать молча», которая привлекла ваше внимание, написана в разделе «С чего начать». Мой опыт говорит, что если никогда не работал целенаправленно над эффективностью, то надо потренироваться на себе, а потому пробовать работать с командой. Могу, разумеется, ошибаться, но пока вроде жизнь это подтверждала.
В данной статье — не синтетические показатели, хотя они тоже входят в сферу интересов.
Здесь просто измерение результатов работы программистов, и работа над эффективностью с использованием этих цифр.
Цифры у меня не являются определяющими в анализе процесса разработки, т.е. они не дают ответа на вопрос, как сделать процесс эффективнее. Но без них ответа вообще не будет. Определяющими являются наблюдение, анализ и эксперименты. Но это не тема данной статьи.
Здесь речь о работе над своей эффективностью, а не о работе над задачами. Работать над эффективностью лучше молча.
Если начать с того, что попытаться всех вокруг убедить в необходимости работать над своей эффективностью, то с высокой вероятностью все равно в одиночестве останетесь.
2. Да. Пете надо добавить чуть-чуть — делать свои решения, которые лучше предложенных. Или хотя бы предлагать.
3. Да, это само собой. В публикации предполагается, что программист толковый, и сразу это понимает, без доп.исследований. Но нас в контексте публикации интересует польза для бизнеса, а не для пользователя.
4. Нет. Бизнес — это люди. Собственникам бизнеса очень не хватает честности и правды от подчиненных. Как в мультике «Вовка в тридевятом царстве», где двое из ларца, одинаковых с лица.
5. Нет. Это программисту решать. «Я — программист» — это не приговор, и не конечная точка пути. Она вполне может быть начальной. Каждый сам решает.
6. Нет и Да. Зависит от выбранной вами зоны ответственности. Если вы работаете от задачи собственника, то такие отмазки не прокатят, а потому и проблем таких не возникнет.
7. Ни в коем случае.
Конкретно эта доработка выглядит полезной. Только я бы сделал не Ctrl+A, а любое другое сочетание клавиш, не используемое виндой.
Но с точки зрения бизнеса это — суррогат. Никакой пользы не будет.
На первый взгляд кажется, что сэкономится время пользователей — да, сэкономится, но они, по закону Паркинсона, просто станут работать медленнее.
Если применительно к программированию, то нужно понимать, ради кого делается программирование. Цепочка получается короче — пользователю нужно одно, программист делает другое. Цели бизнеса вообще не рассматриваем — вполне вероятно, что то, что нужно пользователю, не имеет ценности для бизнеса. Если при этом оно еще и реализовано коряво, то совсем плохо. А может, и не плохо — какая разница, хорошо или плохо сделано то, что никому не нужно?
Например, программист создает и запускает внутренний корпоративный портал для компании, состоящей из 5 человек.
Или оптимизирует код корпоративной информационной системы, который используется раз в год для формирования фин.результатов, снижая время исполнения с 10 минут до 1 минуты.
Или подключает к сайту компании, работающей только по гос.заказу, систему общения с пользователями.
Вот классическая схема поэтапного «суррогатирования»:
Если авария произошла именно из-за системы управления, то — да, это суррогат.
Просили систему, которая защитит от аварии, получили систему, которая не защитила.
В вашем примере цели мне, увы, не известны.
Вот есть такая система — JIRA. Сама по себе она не плохая, не хорошая. Не суррогат и не то, что нужно.
Если ее вручить дворнику для повышения его эффективности, то JIRA станет суррогатом.
Потому что «нафига козе баян».
Программист и его код в данной публикации — черный ящик, который либо делает продукт, либо не делает его.
Здесь имелся в виду суррогат не ожидаемый, а подсунутый :)
Покупал как-то минералку на вокзале, оказалась вода с содой. Вот такой суррогат.
Или, из бизнеса — покупаем автоматизацию бизнеса с целью сокращения затрат, получаем повышение затрат, расширение бухгалтерии и штат программистов в придачу.
не совсем. Я, скорее, экспериментирую и пробую разные варианты — от следования их правилам, до их полного разрушения. Иногда, ради эксперимента, делаю вид, что я такой же, как они. Это как игра. В публикации отражены 4 состояния, через которые я проходил в этой игре — сопротивляться, работать за них, возглавить их, договориться с ними.
Лично мое мнение — ради жизненного опыта надо иногда поучаствовать в подковерных играх. Не настаиваю. Это увлекательно, если границы не переходить.
У меня почти так же, я предпочитаю создавать и пользоваться абстрактными настраиваемыми инструментами, чтобы делать с их помощью быстрое прототипирование. Там обычно и кода-то нет, мышкой все натыкивается, или живет в БД как временный код и запросы.
Это не значит, что качество не важно. Просто не является предметом рассмотрения данной публикации.
Не стоит привязывать систему мотивации к показателям решения задач программистами, иначе будет так, как вы описали в комментарии.
Мой опыт говорит, что так делать не стоит. Подробнее писал здесь, в разделе Scrum.
За время работы над эффективностью лично у меня сложилось мнение, что ключевой мотиватор, который заставляет людей работать быстрее и лучше — их собственное стремление к развитию, повышению компетенций и личному успеху.
Отдельной строкой выделяется компетенция «работать эффективно» — это ведь не чисто технический навык. Но является конкурентным преимуществом.
Тема повышения эффективности и скорости разработки интересна?
Эффективность падавана не повышается сама собой, это результат наших совместных усилий, экспериментов и изменений в процессе работы.
На оси Y — сумма баллов (story point) выполненных в спринте работ.
Обратите внимание — фраза «работать молча», которая привлекла ваше внимание, написана в разделе «С чего начать». Мой опыт говорит, что если никогда не работал целенаправленно над эффективностью, то надо потренироваться на себе, а потому пробовать работать с командой. Могу, разумеется, ошибаться, но пока вроде жизнь это подтверждала.
Здесь просто измерение результатов работы программистов, и работа над эффективностью с использованием этих цифр.
Цифры у меня не являются определяющими в анализе процесса разработки, т.е. они не дают ответа на вопрос, как сделать процесс эффективнее. Но без них ответа вообще не будет. Определяющими являются наблюдение, анализ и эксперименты. Но это не тема данной статьи.
Если начать с того, что попытаться всех вокруг убедить в необходимости работать над своей эффективностью, то с высокой вероятностью все равно в одиночестве останетесь.
Не просто замечаю, а настаиваю на этом. Видимо, не слишком явно. Хотя вроде в начале текста поместил.
Мужскому варианту посвящен целый раздел публикации, называется "Гадость". Там про то, как выглядит использование мужчиной женского подхода.
И напомню: речь не о мужчинах и женщинах, а о подходах, названных в их честь. Оба пола одинаково применяют оба подхода.