Обладая знаниями в области программирования, менеджеры смогут по-другому взглянуть на свой продукт.
Хорошо известно, что инженеры-программисты - одна из самых высокооплачиваемых профессий в наши дни, а не самая высокая, но вы можете получать хорошую зарплату, занимаясь программированием каждый день. Тогда многие люди думают, что работать инженером-программистом - это круто, вы можете проводить время, отдыхая, играя в игры, и вы работаете не так много, как любой другой человек, которому платят меньше. Конечно, работать инженером-программистом, но о чем никогда не говорят, так это о том, что мы, разработчики, работаем не на компьютеры, а на людей. И некоторые из этих людей - наши начальники.
Конечно, у нас есть великие лидеры, которые решительны, но иногда начальник нашего босса может быть не таким решительным. Смотрим в основном только на результаты и сроки. Особенно, если речь идет о системах, которые могут широко потребляться. Запрашивать сроки выполнения, когда мы пытаемся работать с гибкой методологией. Я думаю, что спринт и сроки выполнения - это две вещи, которые должны согласовываться между заинтересованными сторонами и владельцами продуктов.
Руководство довольно прагматично с точки зрения того, что нужно доставить и когда это должно быть доставлено, без учета реальных усилий по внедрению или исправлению чего-либо в их собственной системе. Затем у нас есть средняя позиция, которая помогает в общении между разработчиками и менеджерами, техническими лидерами.
Технические лидеры несут ответственность в основном за управление ожиданиями сторон, понимание потребностей менеджеров и технические усилия по разработке того, что необходимо для развития.
Обычно технический руководитель должен объяснить, насколько сложно что-то изменить в устаревшем коде, несмотря на то, что это наследие компании, это все еще старый код, который необходимо изменить. Кроме того, кто-то в этой должности часто сталкивается с такими проблемами, как.
Я говорю: Итак, мы должны реализовать это новое приложение в местах X, Y и Z, но также нам нужно позаботиться о производительности, потому что оно будет активно использоваться каждый день.
Менеджер говорит: Хорошо, сколько времени это займет?
Любезно отвечаю: 3 месяца
Менеджер: Хорошо, тогда каков наилучший сценарий?
Вот как это бывает, я всегда уже объясняю сценарий фиксированного случая, учитывая, сколько времени это займет, и какие знания команды для этого и так далее.
