Комментарии 50
НЛО прилетело и опубликовало эту надпись здесь
Мне кажется или это полностью объясняет то, что о нем мало кто слышал?
Всё здорово, а больше всего я за 11 пункт!
PS: люди, которым не нравится статья, вы точно послесловие прочитали?
PS: люди, которым не нравится статья, вы точно послесловие прочитали?
«Благодаря этому навыку я вошел в историю как один из трех величайших руководителей проектов и направлений – наряду с Николо Маккиавели и Стивом Джобсом.»
Самоирония — это замечательно. Если это конечно ирония…
«довелось поработать примерно с 3 875 000 программистов»
«все мои поручения в точности выполняло более 95% – т.е. целый 1 000 000 программистов»
У меня с арифметикой проблемы или?..
Самоирония — это замечательно. Если это конечно ирония…
«довелось поработать примерно с 3 875 000 программистов»
«все мои поручения в точности выполняло более 95% – т.е. целый 1 000 000 программистов»
У меня с арифметикой проблемы или?..
Ничего особенного, но весело написано :)
Макиавелли зовут Никколо. Он не какой-то там «Ник».
Интересно, Кен Нортон знает что Джобс нарушал 1 пункт, и некоторых кто с ним работал это бесило.
В иллюстрации не хватает «Безумный, просто Безумный» :)
А «Сумма технологий» — это скромненько так назвали фирму? Ну типа Джобс-Макиавелли-Я и Лем-Уэлс-Я?
«Послесловие» меня разочаровало:(
Применил все правила сразу и уже к часу дня все разбежались.
Что я делал не так и кто возместит убытки?
Что я делал не так и кто возместит убытки?
Так зачем вам впустую тратить время программистов, привлекая их к проекту до стадии программинга? Прийдя в офис к архитектору, вы не встретите там пинающих балду строителей. Зовите их, только когда вы продумали всю стратегию, все со всеми обсудили, и осталось только написать код.
А вот здесь «совет» не однозначный. Действительно, зачем привлекать программистов на стадии обсуждения архитектуры или бизнес-задач проекта с архитектором, аналитиком или инженером? Последние должны знать как предметную область, так и возможности программирования, и выдавать реальное ТЗ для программистов. Естественно, подразумевается, что все роли в процессе проектирования и разработки ПО распределены по разным людям и программист программирует, а архитектор проектирует и осуществляет авторский надзор.
А еще это частенько заставляет нарушать пункт 5, отвлекая программистов от выполнения текущего проекта на планирование следующего, который возможно будет начат буквально с года на год. И, конечно же, эти проектные совещания не входят в план ни одного из проектов разработки, соответственно финансируются за счет разработчиков.
Это, безусловно, необходимо, но нужен баланс и понимание от менеджеров за счет чьего времени проводятся эти совещания.
Это, безусловно, необходимо, но нужен баланс и понимание от менеджеров за счет чьего времени проводятся эти совещания.
Прочитайте послесловие.
Я прочитал. Я про то, что совет выглядит разумным, а не вредным. Руководителю проекта (внутреннему заказчику) действительно обычно нет нужды обращаться к программистам (рядовым исполнителям) и обсуждать с ними детали реализации, иначе рискует погрязнуть в деталях, а то и холиварах тиа какой фреймворк или либу выбрать, а может писать велосипед. Должна быть иерархия, по-моему. Как минимум трехуровневая: руководитель (менеджер) проекта, решающий бизнес-задачи — архитектор (аналитик, ведущий инженер-программист и т. п.), конвертирующий их в технические — программисты, решающие технические задачи. Если второй уровень недостаточно компетентен и/или авторитетен среди исполнителей, чтобы принять глобальное техническое решение единолично, то он должен взять таймаут и обсудить проблему с исполнителями.
Руководителю проекта (внутреннему заказчику) действительно обычно нет нужды обращаться к программистам (рядовым исполнителям)Это смотря какие роли выполняет РП. В моей практике, например, заказчиком является не РП, а ПМ(продукт-менеджер).РП же — координатор исполнителей, планировщик, главный ответственный и приниматель оперативных решений.
del
Слишком толсто. Надо чтобы мы начали о чем то догадываться где — то к середине, а не в начале.
P.S не могу видеть уже печеньки, почему нету фрозен йогурта?
P.S не могу видеть уже печеньки, почему нету фрозен йогурта?
Отлично!
Особенно «Прийдя в офис к архитектору, вы не встретите там пинающих балду строителей».
Вообще, софт производства крупных компаний (почти всех) оставляет впечатление, что делали его по этому руководству.
Особенно «Прийдя в офис к архитектору, вы не встретите там пинающих балду строителей».
Вообще, софт производства крупных компаний (почти всех) оставляет впечатление, что делали его по этому руководству.
К сожалению зная «как не надо» мы все равно не узнаем «как надо».
А чем таким руководил Макиавелли? Городской стражей?
до послесловия — хотелось прочно уйти во фриланс.
Слишком тонкая шутка для нашего цирка.
Так вот с кого слямзили в свое время друга Барби! Офигенный, просто офигенный!
Александр, перелогиньтесь! =)
Я знаю такого человека!
Прямо как с него все писано… нда… это было что-то…
Прямо как с него все писано… нда… это было что-то…
С очень многим не согласен. Например, возьму первые пункты только. «Приписывайте все заслуги себе». То есть пирог руководителю, а крошки от него команде? Руководитель без команды — ничто, а вот команда — уже хоть что-то.
«Не берите на себя вину». Если кто-то в отделе косячит и вышестоящее начальство его гнобит, его руководитель должен и даже обязан его защищать и, возможно, даже брать вину на себя. Ведь это он ответственный за свою команду. Это важно.
Да, кто-то накосячил, но на это были какие-то причины. Руководитель должен внутри своей команды решать такие вопросы и он должен на него как-то влиять. Но кто-то «из вне» не смеет предъявлять притензии работнику. Если руководитель будет это позволять делать, остальные участники команды увидят в своем руководителе подхалима к вышестоящему руководству и не будут видеть какой-то поддержки и, в конце концов, утратят доверие к нему.
Про остальные пункты уже говорить не буду.
«Не берите на себя вину». Если кто-то в отделе косячит и вышестоящее начальство его гнобит, его руководитель должен и даже обязан его защищать и, возможно, даже брать вину на себя. Ведь это он ответственный за свою команду. Это важно.
Да, кто-то накосячил, но на это были какие-то причины. Руководитель должен внутри своей команды решать такие вопросы и он должен на него как-то влиять. Но кто-то «из вне» не смеет предъявлять притензии работнику. Если руководитель будет это позволять делать, остальные участники команды увидят в своем руководителе подхалима к вышестоящему руководству и не будут видеть какой-то поддержки и, в конце концов, утратят доверие к нему.
Про остальные пункты уже говорить не буду.
Статья, похоже, задумана как «вредные советы», но по сути изложены весьма полезные и практичные идеи.
Кроме «5. Как следует упорядочьте их работу.» и «8. Не стесняйтесь отвлекать их от работы.», пожалуй.
Хотя, может и они имеют смысл.
Кроме «5. Как следует упорядочьте их работу.» и «8. Не стесняйтесь отвлекать их от работы.», пожалуй.
Хотя, может и они имеют смысл.
А интересный подход — не сообщить что делать надо, а чего делать не надо. Я думал я один так размышляю.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Кен Нортон. Как работать с программистами