Не совсем так. Речи о качестве кода здесь не идет, только о том, нужен ли продукт бизнесу.
Программист и его код в данной публикации — черный ящик, который либо делает продукт, либо не делает его.
Здесь имелся в виду суррогат не ожидаемый, а подсунутый :)
Покупал как-то минералку на вокзале, оказалась вода с содой. Вот такой суррогат.
Или, из бизнеса — покупаем автоматизацию бизнеса с целью сокращения затрат, получаем повышение затрат, расширение бухгалтерии и штат программистов в придачу.
вы позиционируете себя борцом с системным управленческим бардаком <...>, но играете уже по их правилам
не совсем. Я, скорее, экспериментирую и пробую разные варианты — от следования их правилам, до их полного разрушения. Иногда, ради эксперимента, делаю вид, что я такой же, как они. Это как игра. В публикации отражены 4 состояния, через которые я проходил в этой игре — сопротивляться, работать за них, возглавить их, договориться с ними.
Лично мое мнение — ради жизненного опыта надо иногда поучаствовать в подковерных играх. Не настаиваю. Это увлекательно, если границы не переходить.
Для меня первое правило разработки — делать так, чтобы потом не переделывать, т.к. обычно переделывать времени нет.
У меня почти так же, я предпочитаю создавать и пользоваться абстрактными настраиваемыми инструментами, чтобы делать с их помощью быстрое прототипирование. Там обычно и кода-то нет, мышкой все натыкивается, или живет в БД как временный код и запросы.
Здесь речь не о плохом коде, а о бессмысленных с точки зрения изменениях в информационной системе. Т.к. качество работы программиста, качество исполнения не рассматривается вообще.
Это не значит, что качество не важно. Просто не является предметом рассмотрения данной публикации.
Да, своей цитатой я выразил согласие с тем, что вы пишете.
Не стоит привязывать систему мотивации к показателям решения задач программистами, иначе будет так, как вы описали в комментарии.
Например, привязка системы мотивации к объемам выполненных задач в спринте может дать лазейку для внешних паразитов – человека станет стремиться не к результату, а к избеганию чувства вины за низкий KPI (сами понимаете, перед кем чувство вины).
Мой опыт говорит, что так делать не стоит. Подробнее писал здесь, в разделе Scrum.
За время работы над эффективностью лично у меня сложилось мнение, что ключевой мотиватор, который заставляет людей работать быстрее и лучше — их собственное стремление к развитию, повышению компетенций и личному успеху.
Отдельной строкой выделяется компетенция «работать эффективно» — это ведь не чисто технический навык. Но является конкурентным преимуществом.
Буду признателен за вопросы — нужно знать, о чем написать в первую очередь, а то бэклог публикаций большой.
Тема повышения эффективности и скорости разработки интересна?
Это разные вещи — работа над своей эффективностью и работа над эффективностью команды. Свою можно повышать молча. Чужую молча не получится.
Эффективность падавана не повышается сама собой, это результат наших совместных усилий, экспериментов и изменений в процессе работы.
На оси Y — сумма баллов (story point) выполненных в спринте работ.
Обратите внимание — фраза «работать молча», которая привлекла ваше внимание, написана в разделе «С чего начать». Мой опыт говорит, что если никогда не работал целенаправленно над эффективностью, то надо потренироваться на себе, а потому пробовать работать с командой. Могу, разумеется, ошибаться, но пока вроде жизнь это подтверждала.
В данной статье — не синтетические показатели, хотя они тоже входят в сферу интересов.
Здесь просто измерение результатов работы программистов, и работа над эффективностью с использованием этих цифр.
Цифры у меня не являются определяющими в анализе процесса разработки, т.е. они не дают ответа на вопрос, как сделать процесс эффективнее. Но без них ответа вообще не будет. Определяющими являются наблюдение, анализ и эксперименты. Но это не тема данной статьи.
Здесь речь о работе над своей эффективностью, а не о работе над задачами. Работать над эффективностью лучше молча.
Если начать с того, что попытаться всех вокруг убедить в необходимости работать над своей эффективностью, то с высокой вероятностью все равно в одиночестве останетесь.
Все просто — метафоричность и образность речи. Лучше понимается, лучше запоминается, проще представить аналогию и понять суть.
Типичный пример — scrum. Само слово scrum, или например спринт — метафоры, понятные образы, с нужной коннотацией. Автор мог назвать методику, например, Управление проектами, а спринт — периодом, но это было бы скучно и не запомнилось бы.
Как вы сами упомянули, ваш подход, с большой вероятностью, будет невозможно воспроизвести
не напомните, где я это упомянул?
Люди, которых я научил этому подходу, воспроизводят его каждый день.
Научная теория, которую вы упомянули в первом комментарии, воспроизводима? Можете найти примеры ее применения в управлении? А если нет, то какой от нее в этой жизни прок?
Но роль одного человека в истории ничтожна
Вы же не подумали, что я собираюсь в историю войти? Если бы собирался, то вся ваша критика была бы уместна. Но я в другой системе координат.
В системе координат научного подхода я был, когда в аспирантуре учился. Это совсем другой мир. Цель науки — наука. Все. Точка.
Главный критерий в науке — научная новизна. Неважно, будет ли какая-то польза, или вообще применение. Главное — новизна. Чтобы очередная диссертация или исследование, которая ложится на пыльную полку, имела признак «это что-то новое».
Применение научных и ненаучных методов — совсем другая специальность, с принципиально другими критериями оценки. Там насрать, новое вы делаете или старое. Главное — достигаете вы результата или нет.
Так вот, я — из второй категории. Когда выйду на пенсию, обязательно напишу книгу или докторскую по своей практике. Но, чтобы написать о практике, нужна практика. И результаты — крутые, воспроизводимые, понятные.
Мои результаты — воспроизводимы. Конкретно этот подход — трижды, с возрастающей эффективностью. Сейчас, на данный момент, по итогам этой конкретной недели, эффективность имеет коэффициент x5.
Медицина — отличный пример, только он совсем о другом. В медицине открытия рождаются в практике, и в практику переходят.
P.S. Вообще, такое впечатление, что вы изначально поняли раздел, к которому относится публикация. Здесь нет научной новизны, научной теории, отсылки к науке. Вообще слова «наука» нет. Это статья практика для практиков.
Любую информацию практиков в вашей системе оценки ждет минус. Точно также, если кто-то будет оценивать публикации по системе «текст написан правильным ямбом?», то опять все получат минус.
Смысл только какой?
Мало того, в гибридном, творческо-разработческом коллективе он, скорее всего, только снизит эффективность
именно в таком коллективе подход родился, развился и показал свою эффективность.
Почему вы считаете, что в задачах управления этот принцип не работает?
Дружище, это не я так считаю, это реальность. Причина проста — в управлении важно то, что работает. Научное, не научное, велосипед, не велосипед — не важно.
Если вы эффективно управляете, никто не будет делать git clone вашего метода управления и читать ваш код, чтобы убедиться, не изобрели ли вы велосипед. Всем на это насрать.
Не насрать только написателям рефератов и соискателям на степень кандидата каких-нибудь наук. Но тут проблема — их труды потом нужны тоже только школьникам, студентам и аспирантам.
Ключевая задача и боль управления — практика и результаты. Но многие слишком увлекаются методиками, наукой и поиском плагиата.
Вот вы пишете про классификацию по типам личности, Личко упомянули.
Сколько эффективных менеджеров вы знаете, которые на практике применяют эти научные знания?
А плагиаторов, которые изобрели велосипеды на основе классификации по типам личности, знают и эффективно применяют все толковые менеджеры. Я говорю о плагиаторах типа Гоулмана с его типами лидерства, Белбине с его ролями в команде и т.д.
Подход и методы любого из них — плагиат с глубоконаучных теорий. Но эти подходы работают, и только поэтому они известны.
Или, например, очень популярный сейчас в управлении Scrum. С ним знакомы все, кому не лень. Его применяют в разработке чаще, чем любую другую методику (кроме методики «просто работать»). Вы знаете, какая научная теория лежит в основе Scrum?
Я знаю — математическая статистика. Почему статистика? Потому что на мат.статистике основан TQM, на ней же основан SPC и TPS. А на них, в свою очередь, основан Scrum. Сазерленд на протяжении всей — всей — книги об этом говорит.
Что теперь, каждого менеджера, который хочет использовать Scrum, отправлять изучать НЗР, квантили, критерий Стьюдента? Или индексы воспроизводимости изучать? Функцию потерь?
Следуя вашей логике
Подчеркну, имеет смысл изучать научные теории, а не публицистику типа популярного некогда Карнеги или там Кийосаки
да, так и надо поступить.
Есть различные научные теории управления системами и персоналом. Нет смысла пытаться создать свою собственную, не ознакомившись предварительно с теми, что уже разработаны до вас
Есть смысл. Я знаю десятки эффективных менеджеров, которые не прочитали ни одной книги по менеджменту, не говоря уж о научных теориях, и никакого связанного с управлением образования не имеют.
Они управляют и учатся управлять интуитивно. Потом, если придет аналитик вроде вас, разберет их метод управления по полкам, и найдет массу аналогий. Вот вы тут из этой теории взяли, тут вот из этой, а это вообще велосипед.
«Вот здорово» — скажет вам эффективный менеджер. «Спасибо дружище, но мне пора, у меня тут эффективное управление, желаю успеха в изучении научных теорий».
Если вам показалось, что я публикацией хотел сказать, будто изобрел уникальный метод или классификацию — вы ошиблись. Вот прям цитирую:
Для себя я обозначил эти подходы как «мужской» и «женский».
Конечно, можно было бежать в библиотеку, и искать аналогии, а не придумывать названия самому. Но нахера?
Я тогда работал менеджером. Если я, используя придуманные неправильные термины, повышаю эффективность разработки в 4 раза, то какая к херам разница, как все это в книгах называется?
Есть люди вроде вас, которые все потом по полочкам разложат, раз времени вагон.
Программист и его код в данной публикации — черный ящик, который либо делает продукт, либо не делает его.
Здесь имелся в виду суррогат не ожидаемый, а подсунутый :)
Покупал как-то минералку на вокзале, оказалась вода с содой. Вот такой суррогат.
Или, из бизнеса — покупаем автоматизацию бизнеса с целью сокращения затрат, получаем повышение затрат, расширение бухгалтерии и штат программистов в придачу.
не совсем. Я, скорее, экспериментирую и пробую разные варианты — от следования их правилам, до их полного разрушения. Иногда, ради эксперимента, делаю вид, что я такой же, как они. Это как игра. В публикации отражены 4 состояния, через которые я проходил в этой игре — сопротивляться, работать за них, возглавить их, договориться с ними.
Лично мое мнение — ради жизненного опыта надо иногда поучаствовать в подковерных играх. Не настаиваю. Это увлекательно, если границы не переходить.
У меня почти так же, я предпочитаю создавать и пользоваться абстрактными настраиваемыми инструментами, чтобы делать с их помощью быстрое прототипирование. Там обычно и кода-то нет, мышкой все натыкивается, или живет в БД как временный код и запросы.
Это не значит, что качество не важно. Просто не является предметом рассмотрения данной публикации.
Не стоит привязывать систему мотивации к показателям решения задач программистами, иначе будет так, как вы описали в комментарии.
Мой опыт говорит, что так делать не стоит. Подробнее писал здесь, в разделе Scrum.
За время работы над эффективностью лично у меня сложилось мнение, что ключевой мотиватор, который заставляет людей работать быстрее и лучше — их собственное стремление к развитию, повышению компетенций и личному успеху.
Отдельной строкой выделяется компетенция «работать эффективно» — это ведь не чисто технический навык. Но является конкурентным преимуществом.
Тема повышения эффективности и скорости разработки интересна?
Эффективность падавана не повышается сама собой, это результат наших совместных усилий, экспериментов и изменений в процессе работы.
На оси Y — сумма баллов (story point) выполненных в спринте работ.
Обратите внимание — фраза «работать молча», которая привлекла ваше внимание, написана в разделе «С чего начать». Мой опыт говорит, что если никогда не работал целенаправленно над эффективностью, то надо потренироваться на себе, а потому пробовать работать с командой. Могу, разумеется, ошибаться, но пока вроде жизнь это подтверждала.
Здесь просто измерение результатов работы программистов, и работа над эффективностью с использованием этих цифр.
Цифры у меня не являются определяющими в анализе процесса разработки, т.е. они не дают ответа на вопрос, как сделать процесс эффективнее. Но без них ответа вообще не будет. Определяющими являются наблюдение, анализ и эксперименты. Но это не тема данной статьи.
Если начать с того, что попытаться всех вокруг убедить в необходимости работать над своей эффективностью, то с высокой вероятностью все равно в одиночестве останетесь.
Не просто замечаю, а настаиваю на этом. Видимо, не слишком явно. Хотя вроде в начале текста поместил.
Мужскому варианту посвящен целый раздел публикации, называется "Гадость". Там про то, как выглядит использование мужчиной женского подхода.
И напомню: речь не о мужчинах и женщинах, а о подходах, названных в их честь. Оба пола одинаково применяют оба подхода.
Все просто — метафоричность и образность речи. Лучше понимается, лучше запоминается, проще представить аналогию и понять суть.
Типичный пример — scrum. Само слово scrum, или например спринт — метафоры, понятные образы, с нужной коннотацией. Автор мог назвать методику, например, Управление проектами, а спринт — периодом, но это было бы скучно и не запомнилось бы.
не напомните, где я это упомянул?
Люди, которых я научил этому подходу, воспроизводят его каждый день.
Научная теория, которую вы упомянули в первом комментарии, воспроизводима? Можете найти примеры ее применения в управлении? А если нет, то какой от нее в этой жизни прок?
Вы же не подумали, что я собираюсь в историю войти? Если бы собирался, то вся ваша критика была бы уместна. Но я в другой системе координат.
В системе координат научного подхода я был, когда в аспирантуре учился. Это совсем другой мир. Цель науки — наука. Все. Точка.
Главный критерий в науке — научная новизна. Неважно, будет ли какая-то польза, или вообще применение. Главное — новизна. Чтобы очередная диссертация или исследование, которая ложится на пыльную полку, имела признак «это что-то новое».
Применение научных и ненаучных методов — совсем другая специальность, с принципиально другими критериями оценки. Там насрать, новое вы делаете или старое. Главное — достигаете вы результата или нет.
Так вот, я — из второй категории. Когда выйду на пенсию, обязательно напишу книгу или докторскую по своей практике. Но, чтобы написать о практике, нужна практика. И результаты — крутые, воспроизводимые, понятные.
Мои результаты — воспроизводимы. Конкретно этот подход — трижды, с возрастающей эффективностью. Сейчас, на данный момент, по итогам этой конкретной недели, эффективность имеет коэффициент x5.
Медицина — отличный пример, только он совсем о другом. В медицине открытия рождаются в практике, и в практику переходят.
P.S. Вообще, такое впечатление, что вы изначально поняли раздел, к которому относится публикация. Здесь нет научной новизны, научной теории, отсылки к науке. Вообще слова «наука» нет. Это статья практика для практиков.
Любую информацию практиков в вашей системе оценки ждет минус. Точно также, если кто-то будет оценивать публикации по системе «текст написан правильным ямбом?», то опять все получат минус.
Смысл только какой?
именно в таком коллективе подход родился, развился и показал свою эффективность.
Дружище, это не я так считаю, это реальность. Причина проста — в управлении важно то, что работает. Научное, не научное, велосипед, не велосипед — не важно.
Если вы эффективно управляете, никто не будет делать git clone вашего метода управления и читать ваш код, чтобы убедиться, не изобрели ли вы велосипед. Всем на это насрать.
Не насрать только написателям рефератов и соискателям на степень кандидата каких-нибудь наук. Но тут проблема — их труды потом нужны тоже только школьникам, студентам и аспирантам.
Ключевая задача и боль управления — практика и результаты. Но многие слишком увлекаются методиками, наукой и поиском плагиата.
Вот вы пишете про классификацию по типам личности, Личко упомянули.
Сколько эффективных менеджеров вы знаете, которые на практике применяют эти научные знания?
А плагиаторов, которые изобрели велосипеды на основе классификации по типам личности, знают и эффективно применяют все толковые менеджеры. Я говорю о плагиаторах типа Гоулмана с его типами лидерства, Белбине с его ролями в команде и т.д.
Подход и методы любого из них — плагиат с глубоконаучных теорий. Но эти подходы работают, и только поэтому они известны.
Или, например, очень популярный сейчас в управлении Scrum. С ним знакомы все, кому не лень. Его применяют в разработке чаще, чем любую другую методику (кроме методики «просто работать»). Вы знаете, какая научная теория лежит в основе Scrum?
Я знаю — математическая статистика. Почему статистика? Потому что на мат.статистике основан TQM, на ней же основан SPC и TPS. А на них, в свою очередь, основан Scrum. Сазерленд на протяжении всей — всей — книги об этом говорит.
Что теперь, каждого менеджера, который хочет использовать Scrum, отправлять изучать НЗР, квантили, критерий Стьюдента? Или индексы воспроизводимости изучать? Функцию потерь?
Следуя вашей логике
да, так и надо поступить.
Есть смысл. Я знаю десятки эффективных менеджеров, которые не прочитали ни одной книги по менеджменту, не говоря уж о научных теориях, и никакого связанного с управлением образования не имеют.
Они управляют и учатся управлять интуитивно. Потом, если придет аналитик вроде вас, разберет их метод управления по полкам, и найдет массу аналогий. Вот вы тут из этой теории взяли, тут вот из этой, а это вообще велосипед.
«Вот здорово» — скажет вам эффективный менеджер. «Спасибо дружище, но мне пора, у меня тут эффективное управление, желаю успеха в изучении научных теорий».
Если вам показалось, что я публикацией хотел сказать, будто изобрел уникальный метод или классификацию — вы ошиблись. Вот прям цитирую:
Конечно, можно было бежать в библиотеку, и искать аналогии, а не придумывать названия самому. Но нахера?
Я тогда работал менеджером. Если я, используя придуманные неправильные термины, повышаю эффективность разработки в 4 раза, то какая к херам разница, как все это в книгах называется?
Есть люди вроде вас, которые все потом по полочкам разложат, раз времени вагон.
Объясненный минус — это плюс. Спасибо.