Comments 8
Таки да. Человеческие взаимоотношения и доверие, как учит нас Френсис Фукуяма, важнее формальных договоров и процедур. В ситуации нестабильности, постоянно меняющихся условий, — особенно.
Бесконечная система, бесконечные отчеты, бесконечные формы, бесконечная формализация всего и вся — основа любой большой корпорации. Без жестких формальных связей между атомами в кристаллической решетке, бриллиант не заблестит. Что бы по этому поводу не думали отдельные атомы углерода :)
Ты же сам пишешь — ушел человек, проект развалился. А если бы вместо человека был некий ресурс, обложенный документацией, на его место воткнулся бы новый ресурс и проект бы жил. Возможно, в итоге проект был бы не гениальным, а просто хорошим — но живым. Мир состоит из синиц в руках — глючных виндовсов, вордов, хромов. Ни одна большая вещь — Эмпайр Стейт Билдинг, Аэробус А380, МС Офис — не была создана маленькой счастливой агильной командой Эриков, Ахметов и Джонов. Потому что путь к Аэробусу труден и долог, и Эрик с Ахметом на нём потеряются — запьют или счастливо женятся, уедут на Гоа или поступят в Кембридж — а Джон один не потянет, потому что ему будет скучно одному.
Ты же сам пишешь — ушел человек, проект развалился. А если бы вместо человека был некий ресурс, обложенный документацией, на его место воткнулся бы новый ресурс и проект бы жил. Возможно, в итоге проект был бы не гениальным, а просто хорошим — но живым. Мир состоит из синиц в руках — глючных виндовсов, вордов, хромов. Ни одна большая вещь — Эмпайр Стейт Билдинг, Аэробус А380, МС Офис — не была создана маленькой счастливой агильной командой Эриков, Ахметов и Джонов. Потому что путь к Аэробусу труден и долог, и Эрик с Ахметом на нём потеряются — запьют или счастливо женятся, уедут на Гоа или поступят в Кембридж — а Джон один не потянет, потому что ему будет скучно одному.
Есть три левела неудачников:
На первом уровне те, кто делает некачественную работу. С багами, с неудобным интерфейсом, и некрасивыми картинками.
Мы (люди) всегда ругаемся на таких неудачников: неудобный сайт, скучное кино, руль отвалился. И все знают как это лечится — повышением квалификации.
У неудачников на втором уровне, работа поставлена профессиональная, но из-за объемов и бесконтроля срываются сроки и поставки. Сидят толковые ребята и тупо не могут договориться между собою.
Именно тут рождается project management, который является необхдимым вспомогательным процессом. И неудачники этого уровня лечатся законами системы. После чего они выдают охренительные проекты.
Но мои самые любимые неудачники на третьем левеле: это те, кто в совершенстве владеет законами системы, но в своем развитии потерял обязательную первую ступень.
Дед пахал землю и управлял фермой, отец управлял фермой и знал что такое пахать землю. А его сын уже и не знает ничего, кроме управления. Ему кажется, что управление это самостоятельная профессия, и ему легко будет перейти с фермы на атомную электростанцию.
Почему ему так кажется? Потому что и на ферме, и на электростанции надо говорить одинаковые слова: день, работник, оплата, риски… Те слова, которые не совпадают — трактор и атом — якобы, будут заботой подвластных инженеров.
Вот именно этим неудачникам я и пытаюсь вправить мозги. Пусть даже считаю такие попытки безнадежными.
На первом уровне те, кто делает некачественную работу. С багами, с неудобным интерфейсом, и некрасивыми картинками.
Мы (люди) всегда ругаемся на таких неудачников: неудобный сайт, скучное кино, руль отвалился. И все знают как это лечится — повышением квалификации.
У неудачников на втором уровне, работа поставлена профессиональная, но из-за объемов и бесконтроля срываются сроки и поставки. Сидят толковые ребята и тупо не могут договориться между собою.
Именно тут рождается project management, который является необхдимым вспомогательным процессом. И неудачники этого уровня лечатся законами системы. После чего они выдают охренительные проекты.
Но мои самые любимые неудачники на третьем левеле: это те, кто в совершенстве владеет законами системы, но в своем развитии потерял обязательную первую ступень.
Дед пахал землю и управлял фермой, отец управлял фермой и знал что такое пахать землю. А его сын уже и не знает ничего, кроме управления. Ему кажется, что управление это самостоятельная профессия, и ему легко будет перейти с фермы на атомную электростанцию.
Почему ему так кажется? Потому что и на ферме, и на электростанции надо говорить одинаковые слова: день, работник, оплата, риски… Те слова, которые не совпадают — трактор и атом — якобы, будут заботой подвластных инженеров.
Вот именно этим неудачникам я и пытаюсь вправить мозги. Пусть даже считаю такие попытки безнадежными.
Я просто это тут оставлю…
programming-motherfucker.com/
programming-motherfucker.com/
Я думаю, что фотосессию горных козлов можно делегировать другому фрилансеру. Не дело заказчику налажиывть и обговаривать все заново с новым человеком — это головная боль исполнителя.
А воробще во всем должна быть золотая середина. ни когда бы не смог рабтать, где план превыше всего, но и в анархичном мире без понимания текущего момента и планов на будующее (хотя бы ближайшее) себя не представляю.
А воробще во всем должна быть золотая середина. ни когда бы не смог рабтать, где план превыше всего, но и в анархичном мире без понимания текущего момента и планов на будующее (хотя бы ближайшее) себя не представляю.
Есть такое понятие — норма управляемости. Для каждого вида деятельности и в зависимости от качеств лидера она разная. Допустим, это 10 человек. Для которых вы можете помнить все назначенные задачи, учитывать все их заморочки и лично держать контакт с каждым. тогда классический PM вы можете заменить на что вашей душе угодно, лишь бы работа двигалась и люди были довольны.
Но вот в крупных проектах ваша схема 100% даст сбой. Далее пройдусь по вашим же разделам.
1. Вас захлестнет лавина неконтролируемых изменений и вы быстро утратите видение конечного продукта. Вам останется только врать заказчику и тоскливо листать ТЗ в преддверие большой порки.
2. Контактное лицо заказчика большого проекта часто является менеджером проектов. Который даже не захочет ничего знать о ваших подходах, а захочет видеть статус-отчеты, план и прогресс по задачам. PM — это язык, на котором вы сможете договориться. Я уже промолчу про политическую возню, сопровождающую распилы крупных бюджетов, которую вам не одолеть без хорошего правового прикрытия (протоколов встреч, официальных писем и т.п.)
3. Если в проекте работает 50-100 человек, вы физически не сможете распространить свою харизму и влияние на них всех. Аналитики не будут знать тестировщиков, программисты будут враждовать с внедренцами и т.п. А вас будут спрашивать спонсоры — каков статус, какие проблемы, что от нас нужно? Вам придется опираться на своих лейтенантов — старших специалистов и линейных руководителей. А тут уж без формализации отношений и менеджмента не обойтись.
4. Про работающее ПО могу согласиться на 100%. Но, опять же, полностью работающее ПО к моменту сдачи первого этапа проекта — непозволительная роскошь. Если проект документируется по ГОСТ, первый этап вы можете сдать одной только документацией и получить до 70% всех денег, чтобы выплачивать немаленькие зарплаты своим «звездам». А ПО допиливается часто после дедлайна по гарантийному письму (к слову о хороших отношениях). Так что если есть готовое отлаженное ПО к середине проекта — это просто супер. Я хочу на такой проект!
Не сочтите за критику, просто мой опыт несколько противоречит вашему. Я в веб-проектах не участвовал, специфики не знаю, но не думаю, что они отличаются от других чем-то, кроме объемов работы.
Но вот в крупных проектах ваша схема 100% даст сбой. Далее пройдусь по вашим же разделам.
1. Вас захлестнет лавина неконтролируемых изменений и вы быстро утратите видение конечного продукта. Вам останется только врать заказчику и тоскливо листать ТЗ в преддверие большой порки.
2. Контактное лицо заказчика большого проекта часто является менеджером проектов. Который даже не захочет ничего знать о ваших подходах, а захочет видеть статус-отчеты, план и прогресс по задачам. PM — это язык, на котором вы сможете договориться. Я уже промолчу про политическую возню, сопровождающую распилы крупных бюджетов, которую вам не одолеть без хорошего правового прикрытия (протоколов встреч, официальных писем и т.п.)
3. Если в проекте работает 50-100 человек, вы физически не сможете распространить свою харизму и влияние на них всех. Аналитики не будут знать тестировщиков, программисты будут враждовать с внедренцами и т.п. А вас будут спрашивать спонсоры — каков статус, какие проблемы, что от нас нужно? Вам придется опираться на своих лейтенантов — старших специалистов и линейных руководителей. А тут уж без формализации отношений и менеджмента не обойтись.
4. Про работающее ПО могу согласиться на 100%. Но, опять же, полностью работающее ПО к моменту сдачи первого этапа проекта — непозволительная роскошь. Если проект документируется по ГОСТ, первый этап вы можете сдать одной только документацией и получить до 70% всех денег, чтобы выплачивать немаленькие зарплаты своим «звездам». А ПО допиливается часто после дедлайна по гарантийному письму (к слову о хороших отношениях). Так что если есть готовое отлаженное ПО к середине проекта — это просто супер. Я хочу на такой проект!
Не сочтите за критику, просто мой опыт несколько противоречит вашему. Я в веб-проектах не участвовал, специфики не знаю, но не думаю, что они отличаются от других чем-то, кроме объемов работы.
Могу написать немного про документацию. В организации, где я работаю, используется ITIL, однако в моей команде разработчиков — Scrumbut (до настоящего Скрама ещё не дошли, однако прилагаю все усилия для этого). Так вот, на несколько систем есть огромные документы, где досканально расписано, что и как работает. Так как команда разработчиков не совсем профессиональна, то половина вообще не открывала данный документ, вторая же почитала в первые несколько дней и потом лишь в очень редких случаях.
При разработке уже полгода-год документация не обновлялась. Оно и понятно, программистам сложно заставить себя открыть огромный документ, найти в нём место, что они меняли и обновить. Потом отправить на проверку, где начнутся дополнительные вопросы и уточнения. Такими темпами реальной разработки будет сделано мало, зато документация будет свежая.
После достаточно продолжительной борьбы с руководством, был найден компромис — к каждому заданию у нас прилагается документ с указанием, какие пакеты были изменены, прошедшие unit тесты и скрипты для базы данных. Так вот, добавив всего один параграф «High level documentation», программист тратит максимум 5 минут, чтобы написать, что же было изменено, да добавить скриншот. В итоге все довольны, хотя огромный документ и не обновляется, но главное тут — отвести глаза от «недокументированности», которую можно будет исправить, выделив человека и дав список заданий, следанных за определённый промежуток времени, благо все мелкие документы фиксируются.
При разработке уже полгода-год документация не обновлялась. Оно и понятно, программистам сложно заставить себя открыть огромный документ, найти в нём место, что они меняли и обновить. Потом отправить на проверку, где начнутся дополнительные вопросы и уточнения. Такими темпами реальной разработки будет сделано мало, зато документация будет свежая.
После достаточно продолжительной борьбы с руководством, был найден компромис — к каждому заданию у нас прилагается документ с указанием, какие пакеты были изменены, прошедшие unit тесты и скрипты для базы данных. Так вот, добавив всего один параграф «High level documentation», программист тратит максимум 5 минут, чтобы написать, что же было изменено, да добавить скриншот. В итоге все довольны, хотя огромный документ и не обновляется, но главное тут — отвести глаза от «недокументированности», которую можно будет исправить, выделив человека и дав список заданий, следанных за определённый промежуток времени, благо все мелкие документы фиксируются.
Sign up to leave a comment.
Agile manifesto (human remix)