Это сокращение time to market или увеличение velocity команды?
Работа по ускорению велась над velocity, одним из результатов стало сокращение time to market.
Time to market уменьшился примерно в 6 раз.
За системой оценок пристально следили, чтобы не уплыла. Смысла уплывать не было, т.к. это была работа для себя, а не на систему мотивации или типа того.
Использовали якори, как описано тут.
Вот цитата, чтоб долго не искать:
Чтобы оценки не уплывали в сторону увеличения или снижения, придумайте себе якорь. Самый простой якорь – решить, что есть задача на 1 балл. Это – бит вашей работы, самое простое из того, что вам приходится делать. Например, добавить поле ввода. Можно придумать не один, а несколько якорей, если вам так проще.
Тут правил нет. Главное – чтобы система оценок не уплывала, иначе начнется не измерение, а иллюзия. В этом смысле проще, когда есть команда, т.к. несколько человек обычно тщательнее следят за системой координат, чем один.
в случае заказной разработки исполнитель не несёт ответственности за недостижение заказчиком бизнес-целей
по факту — да.
Но ведь обещают же?
Смотрим http://v8.1c.ru/erp/:
«Если вы желаете повысить эффективность управления производством и бизнесом, автоматизировать большинство задач на современном цифровом уровне и достичь принципиально новых целевых показателей, «1С:ERP Управление предприятием 2» – это ваш выбор!»
Тут еще можно вывернуться, но заходим по ссылке глубже http://v8.1c.ru/erp/economic_effect.htm:
«Снижение объемов материальных запасов, среднее значение 20%»
«Сокращение расходов на материальные ресурсы, среднее значение 11%»
Даже «Рост прибыли, среднее значение 14%».
Вроде один к одному то, что я написал. С этих цифр начинается, а заканчивается — как всегда, автоматизированной бухгалтерией и каким-то учетом.
Точнее не так. 40-50 — это то, что использовалось в конкретной команде, для получения 4Х.
Сейчас, в другой команде, используется 5-10, с тем же эффектом.
Набор индивидуален, как таблетки от давления.
Заказчик всегда получал автоматизацию бух.учета, <...>, необходимость нанять программиста 1С (а лучше двух) и раздутый штат бухгалтеров, экономистов и прочих операторов, которые вместе с программистом 1С становятся придатками системы.
Высокие зарплаты программистов 1С — это не следствие любви бизнеса, а вынужденная необходимость — кто-то должен обслуживать то, что на хайпе навнедряли.
Полномочия — еще более условная сущность, чем должность. Полномочия даются и забираются элементарно, иногда просто кивком головы. И куча возможностей внутри компании, для использования которых вообще не нужны полномочия.
Подозреваю, что вы сейчас рассуждаете с использованием штампов.
Умный, разбирается в бизнес-системах — значит гендир или его зам.
Умный, разбирается в системах мотивации — значит HR-директор.
Умный, понимает стратегию и оценивает следование ей — собственник, или как минимум гендир.
Это все значки, как у бойскаутов. Просто позиция в системе, на которой стоит человек. Позиция о человеке ничего не говорит — только то, что он смог ее занять.
Посмотрите чуть шире на прототипирование.
Бизнес-программист — это не программист для бизнеса, а программист бизнеса. Модифицирует бизнес-систему, состояющую из информационной системы, бизнес-процессов, системы мотивации, системы управления, целей.
В его ведении — вся система.
И прототипирование у него шире. Например, он может сделать прототип системы мотивации, погонять ее в тестовом режиме 3 месяца, и если при приемлемых затратах она даст прирост эффективности, то доделать и внедрить, в т.ч. автоматизировать.
разработанный по fail fast методике «прототип» лёгко и непринуждённо действиями менеджера может превратиться в «уже созданный продукт, готовый к внедрению»
Да, такой риск есть. Второй раз с таким можно не работать по-пацански.
Либо — иметь такой же выход наверх, как и он. Чтобы присутствовать при «продаже».
Верно. Я в жизни мало встречал бизнес-аналитиков, а те, которые попадались, подходили под определение «на, Боже, что нам негоже» — люди, не нашедшие себе места в жизни. Такие превращались в маркетологов, менеджеров СМК, или аналитиков.
не взваливаю, а предлагаю расширить зону ответственности, компетенции в смежных областях, выйти на другой уровень, работать с другими задачами, зарабатывать другие деньги.
Но решает каждый сам, разумеется.
1. Нет. Скорее «Без ТЗ результат ХЗ, с ТЗ результат говно». ХЗ дает надежду.
2. Да. Пете надо добавить чуть-чуть — делать свои решения, которые лучше предложенных. Или хотя бы предлагать.
3. Да, это само собой. В публикации предполагается, что программист толковый, и сразу это понимает, без доп.исследований. Но нас в контексте публикации интересует польза для бизнеса, а не для пользователя.
4. Нет. Бизнес — это люди. Собственникам бизнеса очень не хватает честности и правды от подчиненных. Как в мультике «Вовка в тридевятом царстве», где двое из ларца, одинаковых с лица.
5. Нет. Это программисту решать. «Я — программист» — это не приговор, и не конечная точка пути. Она вполне может быть начальной. Каждый сам решает.
6. Нет и Да. Зависит от выбранной вами зоны ответственности. Если вы работаете от задачи собственника, то такие отмазки не прокатят, а потому и проблем таких не возникнет.
7. Ни в коем случае.
А можешь вот в этой конкретной форме сделать чтобы Ctrl+A выделяла не все элементы, а только текущий узел и подузлы?
Конкретно эта доработка выглядит полезной. Только я бы сделал не Ctrl+A, а любое другое сочетание клавиш, не используемое виндой.
Но с точки зрения бизнеса это — суррогат. Никакой пользы не будет.
На первый взгляд кажется, что сэкономится время пользователей — да, сэкономится, но они, по закону Паркинсона, просто станут работать медленнее.
В публикации речь о суррогатах применительно к бизнесу, т.е. польза ожидается для бизнеса, а ее нет. Рассматривается влияние не программирования (как физической реализации решения), а влияние выбора решения.
Если применительно к программированию, то нужно понимать, ради кого делается программирование. Цепочка получается короче — пользователю нужно одно, программист делает другое. Цели бизнеса вообще не рассматриваем — вполне вероятно, что то, что нужно пользователю, не имеет ценности для бизнеса. Если при этом оно еще и реализовано коряво, то совсем плохо. А может, и не плохо — какая разница, хорошо или плохо сделано то, что никому не нужно?
Например, программист создает и запускает внутренний корпоративный портал для компании, состоящей из 5 человек.
Или оптимизирует код корпоративной информационной системы, который используется раз в год для формирования фин.результатов, снижая время исполнения с 10 минут до 1 минуты.
Или подключает к сайту компании, работающей только по гос.заказу, систему общения с пользователями.
Вот классическая схема поэтапного «суррогатирования»:
Сорян, не заметил, что вы про систему управления, а не про саму ГЭС.
Если авария произошла именно из-за системы управления, то — да, это суррогат.
Просили систему, которая защитит от аварии, получили систему, которая не защитила.
Суррогат или нет — определяется целями потребителя.
В вашем примере цели мне, увы, не известны.
Вот есть такая система — JIRA. Сама по себе она не плохая, не хорошая. Не суррогат и не то, что нужно.
Если ее вручить дворнику для повышения его эффективности, то JIRA станет суррогатом.
Потому что «нафига козе баян».
Не совсем так. Речи о качестве кода здесь не идет, только о том, нужен ли продукт бизнесу.
Программист и его код в данной публикации — черный ящик, который либо делает продукт, либо не делает его.
Здесь имелся в виду суррогат не ожидаемый, а подсунутый :)
Покупал как-то минералку на вокзале, оказалась вода с содой. Вот такой суррогат.
Или, из бизнеса — покупаем автоматизацию бизнеса с целью сокращения затрат, получаем повышение затрат, расширение бухгалтерии и штат программистов в придачу.
вы позиционируете себя борцом с системным управленческим бардаком <...>, но играете уже по их правилам
не совсем. Я, скорее, экспериментирую и пробую разные варианты — от следования их правилам, до их полного разрушения. Иногда, ради эксперимента, делаю вид, что я такой же, как они. Это как игра. В публикации отражены 4 состояния, через которые я проходил в этой игре — сопротивляться, работать за них, возглавить их, договориться с ними.
Лично мое мнение — ради жизненного опыта надо иногда поучаствовать в подковерных играх. Не настаиваю. Это увлекательно, если границы не переходить.
Для меня первое правило разработки — делать так, чтобы потом не переделывать, т.к. обычно переделывать времени нет.
У меня почти так же, я предпочитаю создавать и пользоваться абстрактными настраиваемыми инструментами, чтобы делать с их помощью быстрое прототипирование. Там обычно и кода-то нет, мышкой все натыкивается, или живет в БД как временный код и запросы.
Работа по ускорению велась над velocity, одним из результатов стало сокращение time to market.
Time to market уменьшился примерно в 6 раз.
За системой оценок пристально следили, чтобы не уплыла. Смысла уплывать не было, т.к. это была работа для себя, а не на систему мотивации или типа того.
Использовали якори, как описано тут.
Вот цитата, чтоб долго не искать:
по факту — да.
Но ведь обещают же?
Смотрим http://v8.1c.ru/erp/:
«Если вы желаете повысить эффективность управления производством и бизнесом, автоматизировать большинство задач на современном цифровом уровне и достичь принципиально новых целевых показателей, «1С:ERP Управление предприятием 2» – это ваш выбор!»
Тут еще можно вывернуться, но заходим по ссылке глубже http://v8.1c.ru/erp/economic_effect.htm:
«Снижение объемов материальных запасов, среднее значение 20%»
«Сокращение расходов на материальные ресурсы, среднее значение 11%»
Даже «Рост прибыли, среднее значение 14%».
Вроде один к одному то, что я написал. С этих цифр начинается, а заканчивается — как всегда, автоматизированной бухгалтерией и каким-то учетом.
Сейчас, в другой команде, используется 5-10, с тем же эффектом.
Набор индивидуален, как таблетки от давления.
Здесь — второе издание, улучшенное и дополненное. Не буква в букву.
Но не настаиваю, могу удалить.
Как и положено.
Высокие зарплаты программистов 1С — это не следствие любви бизнеса, а вынужденная необходимость — кто-то должен обслуживать то, что на хайпе навнедряли.
Умный, разбирается в бизнес-системах — значит гендир или его зам.
Умный, разбирается в системах мотивации — значит HR-директор.
Умный, понимает стратегию и оценивает следование ей — собственник, или как минимум гендир.
Это все значки, как у бойскаутов. Просто позиция в системе, на которой стоит человек. Позиция о человеке ничего не говорит — только то, что он смог ее занять.
Бизнес-программист — это не программист для бизнеса, а программист бизнеса. Модифицирует бизнес-систему, состояющую из информационной системы, бизнес-процессов, системы мотивации, системы управления, целей.
В его ведении — вся система.
И прототипирование у него шире. Например, он может сделать прототип системы мотивации, погонять ее в тестовом режиме 3 месяца, и если при приемлемых затратах она даст прирост эффективности, то доделать и внедрить, в т.ч. автоматизировать.
Да, такой риск есть. Второй раз с таким можно не работать по-пацански.
Либо — иметь такой же выход наверх, как и он. Чтобы присутствовать при «продаже».
не взваливаю, а предлагаю расширить зону ответственности, компетенции в смежных областях, выйти на другой уровень, работать с другими задачами, зарабатывать другие деньги.
Но решает каждый сам, разумеется.
2. Да. Пете надо добавить чуть-чуть — делать свои решения, которые лучше предложенных. Или хотя бы предлагать.
3. Да, это само собой. В публикации предполагается, что программист толковый, и сразу это понимает, без доп.исследований. Но нас в контексте публикации интересует польза для бизнеса, а не для пользователя.
4. Нет. Бизнес — это люди. Собственникам бизнеса очень не хватает честности и правды от подчиненных. Как в мультике «Вовка в тридевятом царстве», где двое из ларца, одинаковых с лица.
5. Нет. Это программисту решать. «Я — программист» — это не приговор, и не конечная точка пути. Она вполне может быть начальной. Каждый сам решает.
6. Нет и Да. Зависит от выбранной вами зоны ответственности. Если вы работаете от задачи собственника, то такие отмазки не прокатят, а потому и проблем таких не возникнет.
7. Ни в коем случае.
Конкретно эта доработка выглядит полезной. Только я бы сделал не Ctrl+A, а любое другое сочетание клавиш, не используемое виндой.
Но с точки зрения бизнеса это — суррогат. Никакой пользы не будет.
На первый взгляд кажется, что сэкономится время пользователей — да, сэкономится, но они, по закону Паркинсона, просто станут работать медленнее.
Если применительно к программированию, то нужно понимать, ради кого делается программирование. Цепочка получается короче — пользователю нужно одно, программист делает другое. Цели бизнеса вообще не рассматриваем — вполне вероятно, что то, что нужно пользователю, не имеет ценности для бизнеса. Если при этом оно еще и реализовано коряво, то совсем плохо. А может, и не плохо — какая разница, хорошо или плохо сделано то, что никому не нужно?
Например, программист создает и запускает внутренний корпоративный портал для компании, состоящей из 5 человек.
Или оптимизирует код корпоративной информационной системы, который используется раз в год для формирования фин.результатов, снижая время исполнения с 10 минут до 1 минуты.
Или подключает к сайту компании, работающей только по гос.заказу, систему общения с пользователями.
Вот классическая схема поэтапного «суррогатирования»:
Если авария произошла именно из-за системы управления, то — да, это суррогат.
Просили систему, которая защитит от аварии, получили систему, которая не защитила.
В вашем примере цели мне, увы, не известны.
Вот есть такая система — JIRA. Сама по себе она не плохая, не хорошая. Не суррогат и не то, что нужно.
Если ее вручить дворнику для повышения его эффективности, то JIRA станет суррогатом.
Потому что «нафига козе баян».
Программист и его код в данной публикации — черный ящик, который либо делает продукт, либо не делает его.
Здесь имелся в виду суррогат не ожидаемый, а подсунутый :)
Покупал как-то минералку на вокзале, оказалась вода с содой. Вот такой суррогат.
Или, из бизнеса — покупаем автоматизацию бизнеса с целью сокращения затрат, получаем повышение затрат, расширение бухгалтерии и штат программистов в придачу.
не совсем. Я, скорее, экспериментирую и пробую разные варианты — от следования их правилам, до их полного разрушения. Иногда, ради эксперимента, делаю вид, что я такой же, как они. Это как игра. В публикации отражены 4 состояния, через которые я проходил в этой игре — сопротивляться, работать за них, возглавить их, договориться с ними.
Лично мое мнение — ради жизненного опыта надо иногда поучаствовать в подковерных играх. Не настаиваю. Это увлекательно, если границы не переходить.
У меня почти так же, я предпочитаю создавать и пользоваться абстрактными настраиваемыми инструментами, чтобы делать с их помощью быстрое прототипирование. Там обычно и кода-то нет, мышкой все натыкивается, или живет в БД как временный код и запросы.