Что дальше?
Почему бы не сделать на этом «кучу бабла»? Ты знаешь что там косяк, тебя «не слушают». Вот тебе готовый Клиент, делай свою Фирму, пиши свой код и продавай этому клиенту. Переиграй «ничтожных людишек» :)
Выполнил свою работу ?! Только не понятно, почему Scrum (Planing Poker) запрещает это же сделать разработчику А?
Да потому что это не-вы-год-но!
Возможно я уже перерос ходить «с фигой в кармане», но почему невыгодно мне, как разработчику, сказать про косяки заранее?
Если я вижу косяки, и начинаю пинать всех с вопопросами «Вы уверены что нужно именно сделать именно так, потому что есть следующие риски… ?»
Я смотрю обратную связь Работодателя, Клиента. Если я вижу, что их реакция «неадекватная», я понимаю что ничем хорошим это не кончится и начинаю себе «стелить соломку».
И через время ухожу «подготовленный»
Если я молчу «с фигой в кармане», через время у Компании начинаются проблемы, я не успеваю подстелить соломку и все равно вынужден уходить. только уже не подготовленным.
Где моя выгода в стратегии «молчания, с фигой в кармане»?
Я сам себе сделал хуже, а не только «злым менеджерам».
Люди, которые приносят вам ТЗ — это совсем не те люди, которые будут пользоваться вашей программой в 99% случаев!
Учим мат часть :) Изучаем работу со стейкходелдерами, изучаем приемы BA и т.д.
менеджеры будут обсуждать неделю куда всунуть кнопку «пересчитать итог» и каким цветом её лучше выделить,
Не менеджерское/барское дело «кнопки красить». Пусть займутся своими делами. К примеру сделают RACI матрицу в начале проекта, обеспечат ресурсами и не лезут не в свое дело после.
Нанимают нормальных спецов по UI/UX, дают ресурсы изучать мануалы по дизайну от компаний, обеспечивают софтом для прототипирования и т.д.
Почему то прослеживается усточивая мысль: делать правильно не хотим. изучать как сдеать правильно, тоже не хотим. Потом удивляемтся, почему так? А хто эта сделал ?!
Из бочки варенья и ложки г#вн@, получается бочка г#вн@ + 1 ложка. И не иначе
Глупые — пытаются заменить человеческий потенциал инструкциями и методологиями.
А вот тут я с Вами согласен :)
Корректная трактовка инструкци — это накопленный опыт, как некоторые действия в уже известных ситуация привели к ожидаемому результату (Success stories), что освобождает время на на иные действия.
Например: не суй цальцы в розетку, мойте руки перед едой, не дразните собаку, проверь код что написал, SOLID, Scurm, ISO 27001 и т.д.:)
Так же очевидно, что они не запрещают и дейстовать иначе в аналогичной ситуации и вырабатывать иные «инструкции».
Программу поставили клиенту и после полугода эксплуатации выяснились проблемы в расчётах в ТЗ,
Привет Agile и иже с ними.
внимательно изучил ТЗ и в ходе реализации нашёл в нём ошибки, поднял вопрос до аналитиков, а потом и до менеджеров и потратил на реализацию в результате в 2 раза больше времени, чем было по плану.
Молодец. Выполнил свою работу ?! Только не понятно, почему Scrum (Planing Poker) запрещает это же сделать разработчику А?
В любом нормальном процессе разработки, такие косяки просто не дойдут до разработки, поскольку они тормознутся на этапе рассмотрения критериев приемки для User Story.
В первом случае — разбирательства (возможно судебные), потеря денег и имиджа компании. Во-втором случае — ничего.
В первом случае тоже не будет никаких судебных разборок:
сделано по ТЗ.
Клиент провел приемо-сдаточные испытания или получил протоколы тестов от Подрядчика
Да. В этом и проблема.
Слишком много «человеческих» переменных. А процессы пытаются это влияние и зависимость уменьшить.
Женщину достали, автомат поставили. (с)
Извините, но вопрос внутренней мотивации и психологии разработчика никак не относится к методологии и ее не корректному применению.
Никакая методология управления не говорит: Менеджер должен унижать своих коллег, Плевать им в чашку с кофе и гадить каждому разработчику на клавиатуру, Обращаться к нему иначе как «Эй ты раб презренный!!!»
Но в реальности что происходит, когда разработчику не интересно? Он с трудом вымучил 2 функции и сидит тупит.
В реальности? Если вышел за «рамки»? Сначала ему предложат объясниться «Какого хрена ?!» Потом, ему предложат пойти поискать другой «интересный проект»…
Что значит «болеть душой за дело»? Это бесплатно работать ночами? Рвать на груди рубашку и с криком «вы все козлы» деплоить самопальный «гениальный» код на сервера клиента?
Я не очень понимаю, почему вдруг разработчик перестает «болеть душой за дело» или почему вдруг должен начать «болеть душой за дело»?
И как Работодатель должен стимулировать «болеть душой за дело»? Взять любимого хомячка в заложники или дать «сахарные губки» и Негра с опахалом?
Условия работы оговорили? Оговорили.
Заключили контракт и пусть себе разработчик сам покупает и негра с опахалом и «сахарные губки» или что ему еще надо.
Есть условия получше? Пусть перебирается.
От «болезни душой за дело», обычно или душевные болезни могут развиться, или седые волосы или давление поднимется…
Видел людей которые под капельницей полежали, после такой вот «болеть душой за дело»… Нифига они не рады такому
А кто мешает «творить» разработчику в его области ответственности?
Разработчик должен понимать, что он предоставляет «сервис разработки» для своего Работодателя и Клиента. Этот «предоставленный сервис» обязан быть выполнен в первую очередь с заранее оговоренным качеством и ценой.
С этот точки зрения разработчик ничем не отличается для Работодателя и Клиента от оператора сотовой связи, провайдера интернета, облачного сервиса и т.д.
Ну до чего же трудно доходит. Ну нельзя оценить риск и выбрать стратегию, если не знать о ситуации, которая грозит.
Давайте последуем стратегии «обезьянка видит — обезьнка делает» и изучим доступные материалы по этой теме (хотя бы кратко) :)
Оценка риска позволяет ответить на следующие основные вопросы:
— какие события могут произойти и их причина (идентификация опасных событий);
— каковы последствия этих событий;
— какова вероятность их возникновения;
— какие факторы могут сократить неблагоприятные последствия или уменьшить вероятность возникновения опасных ситуаций. Кроме того, оценка риска помогает ответить на вопрос: является уровень риска приемлемым, или требуется его дальнейшая обработка?
Ответственные за оценку риска должны знать:
— область деятельности и цели организации;
— уровень приемлемого риска и способы обработки неприемлемого риска;
— способы интеграции процессов оценки риска в процессы менеджмента организации;
— методы оценки риска и способы их применения в процессе менеджмента риска;
— систему подотчетности, распределения ответственности и полномочий в области оценки риска;
— требуемые и доступные ресурсы для выполнения оценки риска;
— способы регистрации и анализа оценки риска.
Причинно-следственный анализ
Краткий обзор
Причинно-следственный анализ является структурированным методом идентификации возможных причин нежелательного события или проблемы. Данный метод позволяет скомпоновать возможные причинные
факторы в обобщенные категории так, чтобы можно было исследовать все возможные гипотезы
Контрольные листы
Краткий обзор
Контрольные листы представляют собой перечни опасностей, риска или отказов средств управления, которые обычно разрабатывают на основе полученного ранее опыта, результатов предыдущей оценки риска или
результатов отказов, произошедших в прошлом.
Анализ воздействия на бизнес
Краткий обзор
Метод анализа воздействия на бизнес (BIA1) ), также известный как оценка воздействия на бизнес, позволяет исследовать, как ключевые виды отказов/нарушений/разрушений могут повлиять на ключевые виды деятельности и процессы организации, а также идентифицировать и количественно определить необходимые возможности для управления организацией в этих условиях. Процесс метода BIA обеспечивает согласование и понимание:
— идентификации и критичности ключевых бизнес-процессов, функций, связанных ресурсов и ключевых взаимосвязей, существующих в организации;
— влияния отказов/нарушений/разрушений на возможности организации достигать установленных критических целей бизнеса;
— необходимых возможностей управления воздействием отказов/нарушений/разрушений и восстановлением нормального хода деятельности организации.
Речь не о том, чтобы не отвечать на вопросы или врать, а о том, что не все нужные вопросы могут быть заданы.
Увы, это так.
Для этого есть стадия идентификация рисков: методы прецедентов, экспертной оценки и еще более 50 методов, которые можно комбинировать между собой.
Есть косяки, которые лучше предотвращать, а не исправлять.
И есть стратегии обработки рисков:
принять риск. Согласиться, что ущерб от сработавщего риска допустим и где-то застраховать сумму для компенсации. Или вложиться в предовтращение риска
отклонить риск: считать, что ущерб от сработавщего риска недопустим. и не делать так, что бы риск возник.
Вы видите только свою часть, и Вы уверены, что можете верно провести хотя бы Business Impact Analysis для своего Работодателя, не говоря уже про Клиента?
Вас уже, наняли что бы снизить уже известные риски
Даже не смотря на все вышеупомянутое, «черного лебедя» никто не отменял :)
Для этого есть «управление рисками», для умных и кто может сам себе сделать процессы, понимая что и зачем.
Для тех кому «чего думать, трясти надо» в Scrum сделали «planing poker» и «ретроспективы» с вопросам: где получились косяки и почему? Как сделать так, что бы их было поменьше на следующих итерациях?
Все в этой части все просто: обезьянка видит — обезьянка делает.
В бизнесе применяется принцип «разумной достаточности», а не учитывается движение всех атомов во вселенной.
В итоге: если нету вопросов, значит косяки не возникли и потери были в допустимых границах, следовательно «разумная достаточность» соблюдена.
А это еще почему?
Я как нанятый спец, в чьи обязанности входит говорить «если… то....» выполняю свою часть контракта.
Свою часть «сделки» я выполнил — предоставил мнение/оценку, и ни одна зараза не сможет сказать «нафига мы его нанимали, если он молчит все время? Табуртка тоже молчит».
Если меня «не слушают», чего мне обижаться? Возможно исходят еще из некоторых долнительных факторов, к которым у меня нет доступа.
Другое дело, если хожу и молчу. Вполне возможно молчание будет трактоваться как «молчит, значит согласен или не видит косяков». Но я свою часть сделки «не выполнил» — не предоставил свою оценку.
Нюанс в том, что донеся свою информацию до собеседника, вы вынуждаете его что-то делать. Ничего не делать — это такое-же тоже решение и тоже «действие».
Понятно, что отсутсвие обратной связи «почему не ценят или не слушают» интересно и может напрягать иногда.
Высказать свое мнение, когда другим на него плевать, — это, очевидно, проявление инициативы. Отсутствие инициативы — это когда ты молчишь в тряпочку, когда тебе не задают вопросов.
Я больше рассматриваю как «гарантированое предоставление и доступность сервиса» :)
Вас нанимали: делать хорошо
Вас нанимали: не делать, чего не просят
Вас нанимали: понимать разницу между первым и вторым.
Вас нанимали: выслушать ваше професиональное мнение.
Вас НЕ нанимали: ВСЕГДА соглашаться с вашим мнением, после того как вы его высказали.
Вас НЕ нанимали: перед вами что-то объяснять, сверх рамок контракта.
Если вы с этим согласны и подписались в контракте, о чем тогда речь?
Если вы профи — свое мнение вы скажете всегда, даже если на него и плевать другим. Зато через время или ваше мнение будет подкреплено и его начнут ожидать, или поймете что всем вокруг в принипе пофиг на вас и друг на друга.
А если вы ходите «с фигой в кармане» вы сам себе злой буратино, поскольку вы не узнаете «куда дует ветер»
Свои бизнес риски тот, кто «платит и музыку заказывает» осознает не хуже вас (в основном), потому что на нем кредит в банке для вашей зарплаты, оплатить офис где вы сидите, инвестиции в будущие проекты и т.д.
Инициатива — это когда я придумал, как увеличить производительность системы в 2 раза без пинков начальства и клиентов.
Вы за чей счет провели измерения и рассчитали экономическую целесообразность?
За чей счет будет развертывание у Клиента на серверах и сопровождение новой версии?
Оно вообще надо Клиенту?
Если вы из своего кармана оплатили виртуалки, провели тестирование и измерения — тогда ладно. Приходите и покажите цифры Заказчику или в следующей итерации воткните свой Самый Лучший Код за 5 минут, а до конца спринта занимайтесь чем хотите.
Если вы за счет Клиента прокачаться — тоже, вариант. Но кто платит тот и музыку заказывает.
Но я не думаю, что в процессе разработки у вас за плечом стоит Злой Менеджер, и говорит «Делай хреново! Делай только ректально!!! А если вы сделали Хорошо, я вам потом сломаю пальцы.»
Хотите сделать в два раза лучше и прокачаться за чужой счет? Возьмите Open Source и ваяйте себе на здоровье :)
Никто в здравом уме не будет давить вашу инициативу если будет понятно что «это хорошо», но никто не будет одобрять непонятные бизнес-риски которые Вы, возможно, спровоцируете своими «инициативами»
Это бизнес! в первую очередь.
Давайте представим, что вместо ПО, это будет хирургия :)
— Я не могу стежки делать шнурками из кожи рыбы, сам вчера нарезал и вымачивал.
— Как-то стерилизацию делать иодом уже не интересно, хочу… серной кислотой попробовать.
— Антибиотки давать по протоколу лечения? Не… давай клистир сделаем из порошка жаб, слышал новое модное на конференции рассказывали по инету.
В конце концов, убили всю инициативу в операционной и я уволился…
Давайте представим, что вам так бухгалтер будет считать и выдавать зарплату «по Scrum что бы было интересно»…
Мотивация в подкидывании идеи?
Что дальше?
Почему бы не сделать на этом «кучу бабла»? Ты знаешь что там косяк, тебя «не слушают». Вот тебе готовый Клиент, делай свою Фирму, пиши свой код и продавай этому клиенту. Переиграй «ничтожных людишек» :)
Кто получает «выгоду»?
Кто оценивает «выгоду»?
Как выгодоприобритатель «выгоду» оценивает?
Возможно я уже перерос ходить «с фигой в кармане», но почему невыгодно мне, как разработчику, сказать про косяки заранее?
Я смотрю обратную связь Работодателя, Клиента. Если я вижу, что их реакция «неадекватная», я понимаю что ничем хорошим это не кончится и начинаю себе «стелить соломку».
И через время ухожу «подготовленный»
Где моя выгода в стратегии «молчания, с фигой в кармане»?
Я сам себе сделал хуже, а не только «злым менеджерам».
Учим мат часть :) Изучаем работу со стейкходелдерами, изучаем приемы BA и т.д.
Не менеджерское/барское дело «кнопки красить». Пусть займутся своими делами. К примеру сделают RACI матрицу в начале проекта, обеспечат ресурсами и не лезут не в свое дело после.
Нанимают нормальных спецов по UI/UX, дают ресурсы изучать мануалы по дизайну от компаний, обеспечивают софтом для прототипирования и т.д.
Почему то прослеживается усточивая мысль: делать правильно не хотим. изучать как сдеать правильно, тоже не хотим. Потом удивляемтся, почему так? А хто эта сделал ?!
Из бочки варенья и ложки г#вн@, получается бочка г#вн@ + 1 ложка. И не иначе
А вот тут я с Вами согласен :)
Корректная трактовка инструкци — это накопленный опыт, как некоторые действия в уже известных ситуация привели к ожидаемому результату (Success stories), что освобождает время на на иные действия.
Например: не суй цальцы в розетку, мойте руки перед едой, не дразните собаку, проверь код что написал, SOLID, Scurm, ISO 27001 и т.д.:)
Так же очевидно, что они не запрещают и дейстовать иначе в аналогичной ситуации и вырабатывать иные «инструкции».
Привет Agile и иже с ними.
Молодец. Выполнил свою работу ?! Только не понятно, почему Scrum (Planing Poker) запрещает это же сделать разработчику А?
В любом нормальном процессе разработки, такие косяки просто не дойдут до разработки, поскольку они тормознутся на этапе рассмотрения критериев приемки для User Story.
В первом случае тоже не будет никаких судебных разборок:
Слишком много «человеческих» переменных. А процессы пытаются это влияние и зависимость уменьшить.
Женщину достали, автомат поставили. (с)
Никакая методология управления не говорит: Менеджер должен унижать своих коллег, Плевать им в чашку с кофе и гадить каждому разработчику на клавиатуру, Обращаться к нему иначе как «Эй ты раб презренный!!!»
В реальности? Если вышел за «рамки»? Сначала ему предложат объясниться «Какого хрена ?!» Потом, ему предложат пойти поискать другой «интересный проект»…
Я не очень понимаю, почему вдруг разработчик перестает «болеть душой за дело» или почему вдруг должен начать «болеть душой за дело»?
И как Работодатель должен стимулировать «болеть душой за дело»? Взять любимого хомячка в заложники или дать «сахарные губки» и Негра с опахалом?
Условия работы оговорили? Оговорили.
Заключили контракт и пусть себе разработчик сам покупает и негра с опахалом и «сахарные губки» или что ему еще надо.
Есть условия получше? Пусть перебирается.
От «болезни душой за дело», обычно или душевные болезни могут развиться, или седые волосы или давление поднимется…
Видел людей которые под капельницей полежали, после такой вот «болеть душой за дело»… Нифига они не рады такому
Разработчик должен понимать, что он предоставляет «сервис разработки» для своего Работодателя и Клиента. Этот «предоставленный сервис» обязан быть выполнен в первую очередь с заранее оговоренным качеством и ценой.
С этот точки зрения разработчик ничем не отличается для Работодателя и Клиента от оператора сотовой связи, провайдера интернета, облачного сервиса и т.д.
Или чем-то отличается?
Давайте последуем стратегии «обезьянка видит — обезьнка делает» и изучим доступные материалы по этой теме (хотя бы кратко) :)
Оценка риска позволяет ответить на следующие основные вопросы:
— какие события могут произойти и их причина (идентификация опасных событий);
— каковы последствия этих событий;
— какова вероятность их возникновения;
— какие факторы могут сократить неблагоприятные последствия или уменьшить вероятность возникновения опасных ситуаций. Кроме того, оценка риска помогает ответить на вопрос: является уровень риска приемлемым, или требуется его дальнейшая обработка?
Ответственные за оценку риска должны знать:
— область деятельности и цели организации;
— уровень приемлемого риска и способы обработки неприемлемого риска;
— способы интеграции процессов оценки риска в процессы менеджмента организации;
— методы оценки риска и способы их применения в процессе менеджмента риска;
— систему подотчетности, распределения ответственности и полномочий в области оценки риска;
— требуемые и доступные ресурсы для выполнения оценки риска;
— способы регистрации и анализа оценки риска.
Причинно-следственный анализ
Краткий обзор
Причинно-следственный анализ является структурированным методом идентификации возможных причин нежелательного события или проблемы. Данный метод позволяет скомпоновать возможные причинные
факторы в обобщенные категории так, чтобы можно было исследовать все возможные гипотезы
Контрольные листы
Краткий обзор
Контрольные листы представляют собой перечни опасностей, риска или отказов средств управления, которые обычно разрабатывают на основе полученного ранее опыта, результатов предыдущей оценки риска или
результатов отказов, произошедших в прошлом.
Анализ воздействия на бизнес
Краткий обзор
Метод анализа воздействия на бизнес (BIA1) ), также известный как оценка воздействия на бизнес, позволяет исследовать, как ключевые виды отказов/нарушений/разрушений могут повлиять на ключевые виды деятельности и процессы организации, а также идентифицировать и количественно определить необходимые возможности для управления организацией в этих условиях. Процесс метода BIA обеспечивает согласование и понимание:
— идентификации и критичности ключевых бизнес-процессов, функций, связанных ресурсов и ключевых взаимосвязей, существующих в организации;
— влияния отказов/нарушений/разрушений на возможности организации достигать установленных критических целей бизнеса;
— необходимых возможностей управления воздействием отказов/нарушений/разрушений и восстановлением нормального хода деятельности организации.
Увы, это так.
Для этого есть стадия идентификация рисков: методы прецедентов, экспертной оценки и еще более 50 методов, которые можно комбинировать между собой.
И есть стратегии обработки рисков:
Вы видите только свою часть, и Вы уверены, что можете верно провести хотя бы Business Impact Analysis для своего Работодателя, не говоря уже про Клиента?
Вас уже, наняли что бы снизить уже известные риски
Даже не смотря на все вышеупомянутое, «черного лебедя» никто не отменял :)
Для тех кому «чего думать, трясти надо» в Scrum сделали «planing poker» и «ретроспективы» с вопросам: где получились косяки и почему? Как сделать так, что бы их было поменьше на следующих итерациях?
Все в этой части все просто: обезьянка видит — обезьянка делает.
В бизнесе применяется принцип «разумной достаточности», а не учитывается движение всех атомов во вселенной.
В итоге: если нету вопросов, значит косяки не возникли и потери были в допустимых границах, следовательно «разумная достаточность» соблюдена.
Я как нанятый спец, в чьи обязанности входит говорить «если… то....» выполняю свою часть контракта.
Свою часть «сделки» я выполнил — предоставил мнение/оценку, и ни одна зараза не сможет сказать «нафига мы его нанимали, если он молчит все время? Табуртка тоже молчит».
Если меня «не слушают», чего мне обижаться? Возможно исходят еще из некоторых долнительных факторов, к которым у меня нет доступа.
Другое дело, если хожу и молчу. Вполне возможно молчание будет трактоваться как «молчит, значит согласен или не видит косяков». Но я свою часть сделки «не выполнил» — не предоставил свою оценку.
Нюанс в том, что донеся свою информацию до собеседника, вы вынуждаете его что-то делать. Ничего не делать — это такое-же тоже решение и тоже «действие».
Понятно, что отсутсвие обратной связи «почему не ценят или не слушают» интересно и может напрягать иногда.
Я больше рассматриваю как «гарантированое предоставление и доступность сервиса» :)
Вас нанимали: не делать, чего не просят
Вас нанимали: понимать разницу между первым и вторым.
Вас нанимали: выслушать ваше професиональное мнение.
Вас НЕ нанимали: ВСЕГДА соглашаться с вашим мнением, после того как вы его высказали.
Вас НЕ нанимали: перед вами что-то объяснять, сверх рамок контракта.
Если вы с этим согласны и подписались в контракте, о чем тогда речь?
Если вы профи — свое мнение вы скажете всегда, даже если на него и плевать другим. Зато через время или ваше мнение будет подкреплено и его начнут ожидать, или поймете что всем вокруг в принипе пофиг на вас и друг на друга.
А если вы ходите «с фигой в кармане» вы сам себе злой буратино, поскольку вы не узнаете «куда дует ветер»
Свои бизнес риски тот, кто «платит и музыку заказывает» осознает не хуже вас (в основном), потому что на нем кредит в банке для вашей зарплаты, оплатить офис где вы сидите, инвестиции в будущие проекты и т.д.
Вы за чей счет провели измерения и рассчитали экономическую целесообразность?
За чей счет будет развертывание у Клиента на серверах и сопровождение новой версии?
Оно вообще надо Клиенту?
Если вы из своего кармана оплатили виртуалки, провели тестирование и измерения — тогда ладно. Приходите и покажите цифры Заказчику или в следующей итерации воткните свой Самый Лучший Код за 5 минут, а до конца спринта занимайтесь чем хотите.
Если вы за счет Клиента прокачаться — тоже, вариант. Но кто платит тот и музыку заказывает.
Но я не думаю, что в процессе разработки у вас за плечом стоит Злой Менеджер, и говорит «Делай хреново! Делай только ректально!!! А если вы сделали Хорошо, я вам потом сломаю пальцы.»
Хотите сделать в два раза лучше и прокачаться за чужой счет? Возьмите Open Source и ваяйте себе на здоровье :)
Никто в здравом уме не будет давить вашу инициативу если будет понятно что «это хорошо», но никто не будет одобрять непонятные бизнес-риски которые Вы, возможно, спровоцируете своими «инициативами»
Давайте представим, что вместо ПО, это будет хирургия :)
— Я не могу стежки делать шнурками из кожи рыбы, сам вчера нарезал и вымачивал.
— Как-то стерилизацию делать иодом уже не интересно, хочу… серной кислотой попробовать.
— Антибиотки давать по протоколу лечения? Не… давай клистир сделаем из порошка жаб, слышал новое модное на конференции рассказывали по инету.
В конце концов, убили всю инициативу в операционной и я уволился…
Давайте представим, что вам так бухгалтер будет считать и выдавать зарплату «по Scrum что бы было интересно»…