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