Комментарии 9
Для технического специалиста нормально проводить время на кухне или в курилке
И я из своих более 50 лет в программировании. более сорока лет считал, что я курю (а курил я не менее пары пачек "Беломора", а с конца 80-х "Явы", в день) только потому, что мне нужно что-то обмозговать и тем, что компьютер медленно транслирует и мне надо занять руки. Но в один прекрасный момент мне просто расхотелось курить. и вот у же скоро десять лет как я не курю. Но самое главное я нашёл чем заменить курение. которое я тратил на обдумывание. Вместо сидения в курилке. я теперь просто хожу:
Ольга Игоревна (лечащий врач) дала мне совет, обязательно каждый день ходить в течение часа или проходить 10 000 шагов.
Про себя я подумал, какая трата времени, но попробовал. Случилось чудо. Когда я иду, то думаю не про ходьбу и, не дай бог, про болячки, а анализирую, что я сделал, как запрограммировал. что надо исправить и как. Оказалось, что в процессе ходьбы я стал намного быстрее расшивать узкие места, находить новые решения и т. д.
Так что со всем в статье можно согласиться. кроме этого постулата.
Вы уважаемый точно не из "службы безопасности" сбербанка?
"Ничто не убивает мотивацию, как долгострой без видимого результата." - прям флэшбэк к прошлой работе...
рекомендую ориентироваться именно на 60-70%. Когда-то давно прочитал это в статье про Google
Лучше смотреть сразу первоисточник DSDM (многа букаф), раздел MoSCoW Prioritization: 60% Must, 20% Should, 20% Could, 0% Won't.
Anything higher than 60% Must Have effort poses a risk to the success and predictability of the project, unless the environment and any technology is well understood, the team is well established and the external risks minimal.
Ну то есть все что выше 60% обязательной работы ведёт к рискам, кроме как вы делаете уж совсем очевидные вещи. Ну или просто рисковый парень по жизни.
Как гласит история, метод приоритизации придумали в 1994 году, а мы узнаем лишь четверть века спустя. Это не критика, просто мысль вслух. Да это не ново, но все актуально.
Стандарты и методологии разработки проработаны в достаточной степени уже давно. Но они объемные как и сама область, поэтому требуют целенаправленного образования. Мы же упорно пытаемся обмануть систему, выбирая замену в виде каких-то клипов и статей уровня хабра.
Спасибо, теперь будет на что сослаться)
Правда если вчитаться, то в тексте по ссылке есть существенное отличие от того, о чем я хотел сказать.
MoSCoW предлагает поделить цели по принципу Парето, отделив условно must have от should have. Я писал про то, что в целом часто не получается сделать ровно те цели, которые ставишь.
Из 10 целей успешно выполняются 6-7, но ты заранее не знаешь какие. Не получается сделать 6 must have, потом взяться за should have.
Вроде бы цель must have, но в процессе выясняется, что ее трудоемкость гораздо выше, чем казалось с самого начала (по той или иной причине). Или ты не успеваешь закрыть предыдущую задачу и не можешь переключить разработчика на новую. А предыдущую на середине бросать тоже нельзя.
Конечно, есть какое-то количество жестких коммитов, где от тебя что-то очень ждут, или от тебя зависят другие команды. Но таких целей должно быть совсем немного, потому что на них нужно перезакладывать ресурсы.
Вы наверное знаете про треугольник scope - cost - time. DSDM в целом это про минимизацию рисков для проектов типа fixed cost + fixed time - для смягчения сработавших рисков безболезненно варьировать можно scope. Но лишь в той части что не must (иначе какой же это тогда must?). Все must задачи лежат на critical path и между ними есть жёсткие зависимости. Если вы продалбывете в спринте must, то весь проект рискует вылететь за рамки и это повод для эскалации и принятия корректирующих мер уровня всего проекта.
Если must задачи получается переставлять местами, то возможно что-то упущенно на этапе планирования, либо у вас просто не хватает людей, чтобы не делать последовательно ту работу, которую можно параллелить. В общем MoSCoW это только часть метода, и чтобы понять логику там лучше читать все целиком.
Одна из главных задач менеджера - создавать у сотрудников ощущение защищенности и стабильности
Это истина! Хороший менеджер получает зарплату за то, что рассеивает в себе зиверты вредного излучения сверху, создавая внутри более благоприятную среду, чем снаружи. Иными словами - он продаёт свою способность абсорбции рисков, причём всех мастей.
Мои принципы в менеджменте ИТ-команд