Pull to refresh

Comments 15

Очень понравилась статья. Добавить бы что должен быть план действий и каждый должен знать свою роль.
План действий составляется в п.5 «Определение целей и задач», но только для классических подходов, так как Agile практики не предполагают четкое определение плана всего проекта. Мне больше всего нравится PBS — Product breakdown structure, который я подсмотрел в PRINCE2. После его составления я поворачиваю его на 90 градусов влево и получается план с измеримыми результатами. Напишу об этом отдельно.
Статья слишком общая. Заменить яхту практически любым другим проектом — будет все то же.
Блин.

>> Это около 1000 морских миль, 10 дней открытого океана, без возможности сойти на берег.
И что, все самое интересное это выводы типа: коммуникация, риски, мониторинг, корректировка, правила, цели и задачи?
По личному опыту складывается ровно такое же ощущение:
Проектный менеджмент — это очевидные, общие и довольно прописные истины.
Проблема в том, что для каждого практического кейса — фраз, описывающих решение оной — несколько десятков. Рабочих из них около десятка, уместных 1-2. Поэтому хорошие статьи по проектному менеджменту очень часто смотрятся как исповедь капитана очевидность. Тем не менее таковыми не являются.
Воспринимайте статью как очевидное перечисление очевидных областей с тем чтобы вы проделали неочевидное для своего проекта — и прошлись по этим областям чтобы понять — закрыты ли они у вас осознанно или «сложились исторически и не очень выгодно».
Да, статья общая. Из моего опыта, даже приведенные элементарные правила не соблюдаются почти никогда.
Мне показалась интересной возможность показать как правила, используемые в ИТ работают в других, казалось бы совершенно чуждых высоким технологиям областях. Более того, именно там их необходимость становится очевидной.
Если статья понравится, буду продолжать подробнее рассказывать что делать в ИТ проектах по каждому пункту. Опыт позволяет, время пока есть.
Так собственно никакой привязке к ИТ в статье нет. Правила проектного менеджмента везде одни и те же, тут вон одни товарищи аэропорт по аджайлу строили например.
Статья слишком общая. Заменить яхту практически любым другим проектом — будет все то же.

Похоже на типичный треннинг. Информации много. Она полезна.
И те, кто «в теме» понимают про себя «да, да, я тоже так делаю» или «а, вот чего я не делаю».
Те, кто не «в теме» просто пропускают мимо ушей большую часть информации.
Расчет на то, что часть из тех, кто «а, вот чего я не делаю» глядя на практические примеры все же начнет эти пункты выполнять. И это повлияет на успешность его проектов.
замыленная статья, както так
UFO just landed and posted this here
Да, в моем примере мы тоже дошли до Португалии. Провал руководителя проекта не всегда означает провал проекта. Хорошая команда может вытянуть проект, даже если руководитель — так себе. Это тоже, хоть и неявно, следует из статьи.
Очень грамотно сформулированная и структурированная статья, на мой взгляд. Конечно, предыдущие комментаторы правы в том, что вроде как эти правила нам всем известны. Но! Они действительно НЕ выполняются. А дальше происходит следующее — разжевывая необходимость их выполнения генерируешь много мусора, наворачиваешь понятия в клубок, у самого уже башка трещит и как просто объяснить прописные истины команде в какой-то момент уже не знаешь — закопался в поисках определения очевидного. Но теперь у меня есть отличный способ — я просто буду кидать ссылку на эту статью :) Тут всё коротко, ясно, по делу и с очень, очень хорошим примером-аналогией про яхту. Спасибо!
У меня яхтенный комментарий. Честно говоря от прочтения статьи душа в пятки ушла от страха, потому что в худшем случае не убыток, а смерть. А при таком бардаке…

Вы действительно шли трансатлантику без связи? У вас не было спутнкового телефона? А прогнозы получали как то? EPIRB то хотя бы был?

Вы в океане снимали паруса и шли под двигателем? А сколько дуло и сколько миль шли?

А когда был броченг сколько дуло когда нормально шли и сколько задуло?
Это же был кетч или йол?

Вы пили воду из яхтеных танков, откуда вода поступает в краны?

Что касается не яхтенной части, мне кажется что статья очень сильно перетянута на сторону менеджмента и опущена инжинерная сторона.
Это хорошо видно на примере с водой. Для ИТ можно привести аналог что мы делаем систему и не учли что она будет использоваться 1000+ юзеров в один момент. Пока мы не сделаем проектирование(а опытный проектировщик скорее всего не допустит такой глупой ошибки, как готовность к многопоточности) мы вообще не видим этот риск.
Я к тому, что без процедуры оценки рисков но с грамотным проектированием вернее не попасть в попу, чем без проектирования но с оценкой рисков.
Понятно что в идеале должно быть и то и то, как например в ATAM(мы кстати один раз проводили).

Для воды аналогично — думаю для опытного капитана это вообще не вопрос что делать с водой. Мене опытным нужно попроектировать(прогнать в уме все плаванье) и только потом! выявлять риски.
Яхтенный ответ.
Связь, конечно, была. И EPIRB и спутниковый ретранслятор. Но реально, при мобильном устройстве это только СМС. Не надо серьезно на это рассчитывать. Впрочем, люди уже 400 лет ходят через океан а связь только последние лет 20-30. Так что это не критично.
При брочинге был шквал от грозового фронта. Сколько дунуло — не знаю, не до того было. По ощущениям 30+. До этого было в районе 10-15, стоял и грот и стаксель на полную…

Про прототипы:
Быстрое проектирование, так же как и AGILE приемы хорошо повышают вероятность успеха проекта, но не всегда их можно применить. Например, это не сработает на проекте с четко определенным результатом по фиксированной цене — а это наиболее часто встречающаяся ситуация пр работах с внешними подрядчиками. Или надо выделять прототип в отдельный этап, но я исключительно редко встречал заказчика, готового выделить деньги на то, что может не иметь продолжения и бизнес-значимого результата.

Я приятно удивлен увидеть статью про яхтинг на Хабре.


Добавлю пару комментариев.


Согласование терминологии

В яхтинге единые правила и терминология МППСС. Единственное что в мировых водах используется английская терминология, а в Российских внутренних водах русская терминология.
У меня с этим были затыки так как большая часть опыта именно во внутренних водах. Но это просто слова, суть одна и та же.


Расходы на топливо, по мнению нового капитана, должны были дополнительно оплачиваться экипажем, хотя владелец говорил о других условиях. Сумма за счет многочисленности экипажа вышла небольшая, около 20 евро. 

Когда у меня был переход по Атлантике 1200 мм, мы за свой счёт залили полный бак, все канистры что были и я ещё уговаривал капитана купить дополнительных канистр и взять с собой топлива побольше, потому что это серьезный переход и свою жизнь я ценю больше.
В последствии, мы сильно жалели, что взяли мало топлива так как у нас вместо обещанных 40 узлов попутного ветра всю дорогу был штиль и топлива до берега не хватило.


Это море. Нужно всегда ориентироваться на самое худшее.


Правда, он ограничился только самыми необходимыми вопросами — сколько яхтенного опыта

По большому счету это все что нужно.
Также желательно заранее узнать у команды об их аллергии, болезнях, списке лекарств, их применении и местоположении. Если у кого-то на борту неожиданно случится приступ, это будет очень не хорошо.


Описывать свои достижения капитан не обязан. Авторитет капитана неоспорим. Это на берегу вы можете сказать, а на воде ваша жизнь зависит от капитана.
Если капитан сказал прыгать за борт, матрос должен тут же исполнять команду.


 «дойти до точки В» и «стараться не повредить яхту» — существенно отличающиеся цели

Почему отличающиеся? Это напрямую связанные цели. На поврежденной лодке вы можете не дойти до точки В и обратное тоже верно.


Первоочередная цель в любом яхтенном переходе это дойти из точки А в точку Б. Желательная цель дойти целыми, но мы помним что жизнь человека ценнее лодки.


Я не знаю какая у вас была ситуация и что вы называете при свежем ветре. Если была отдана такая команда, то на это, я думаю, были причины.


Как уже говорил ранее, команды капитана не обсуждаются.


посуду мыли только при помощи ручной помпы

При наличии ручной помпы, очевидно что пользоваться нужно только ей. Этого не знают только те кто никогда не имел дела с ней.
Это не критика. Я тоже на эти грабли наступал.


капитан не проинструктировал экипаж и вахту о необходимом оповещении его в этой ситуации

Ну это просто смешно.
При любой внештатной ситуации нужно поднимать капитана, даже если он уснул 10 мин назад.
Это ваш косяк, а не капитана.


команды вроде «Уберитесь на камбузе», «Отдайте кормовые»

Ну, мы всё же не в армии.
Команды вроде "Ты идёшь убираться на камбузе" и "Ты встаешь на левый кормовой" четки, понятны, эффективны и особенно важны в интернациональных командах. Но иногда хорошо бы дать право выбора.


В моей практике не редко звучат команды "Подготовится к швартовке" и "Кто на кормовых?".


Подитожу
На мой взгляд, яхтинг больше похож на армию, чем на классический менеджмент.
Матрос который ни чем не занят, плохой матрос.

Sign up to leave a comment.

Articles