После 10 лет работы в качестве ИТ руководителя, когда за плечами уже достаточно выполненных проектов и компаний, а также опыт создания проектного офиса, видишь все вокруг немного иначе. Любую уникальную задачу хочется декомпозировать на подзадачи, расположить их на scrum-доске или на временной шкале, оценить приоритеты, риски, трудозатраты. К сожалению, в реальности, даже элементарные практики из проектного управления соблюдаются не всегда.

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



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


Чтобы вести совместную деятельность, надо понимать друг друга. Перед тем как приступить к проекту, проверьте, что все специфические термины вы понимаете одинаково. В одном из моих проектов, в результате сравнения тезауруса двух компаний, участвующих в проекте, выяснилось, что 40% терминов несут различный смысл. Очевидно, любые документы и договоренности в такой ситуации будут только увеличивать проблемы, так как, глядя на них, люди оперируют совершенно разными объектами.

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

Понимая, что у людей может быть совершенно иная картинка, я информирую людей, с которыми участвую в таких проектах, заранее. Тем не менее, мне известны случаи, когда модные девицы с полным маникюром (не имею ничего против, но при других обстоятельствах) сходили на берег в первом же порту и забывали об этом опыте как о страшном сне. В нашем примере, о котором пойдет речь, возможности выхода из проекта не было — яхтенный переход планировался от Азорских островов до Гибралтара. Это около 1000 морских миль, 10 дней открытого океана, без возможности сойти на берег.

Путешествие состоялось в начале мая текущего года, и проходило с интернациональным экипажем: поляки, немцы, испанец, американец и я, русский. Управлять такой командой с целью достижения общей цели, да ещё в условиях бытовых и внешних сложностей — серьёзная задача, с которой сталкивался не всякий менеджер проекта. Пикантности же ситуации добавляло то, что владелец, который прошёл с половиной этого экипажа предыдущих 2000 миль, должен был срочно отбыть на большую землю и оставил вместо себя нового капитана, поляка, лет около 30, который не знал экипаж, не знал лодку, и как мы разберем дальше, совершил практически все ошибки руководителя проекта.

При этом, на подходе к Азорским островам лодка прошла через шторм и была повреждена, что не позволяло ее нагружать на 100%. Хорошая же новость состояла в том, что большая часть экипажа шла с Канарских островов, и они уже были проверены владельцем на предмет профессионализма, личной совместимости и, что называется, «уже прикачались». Впрочем, все эти детали я узнал уже на месте, так как моя тяга к цели была сильнее природной осторожности.

И тут надо отметить правило, которое мы все знаем и все нарушаем:

2. Согласование условий


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

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

Следующее правило, которое я вспомнил, глядя на приемку лодки новоиспеченным капитаном:

3. Подготовка к проекту


Успех переговоров с клиентом, на которые вы мимоходом заскакиваете между еженедельной встречей с подчиненными и отчётом своему руководителю, существенно зависит от настроения и состояния клиента. Переговоры, к которым у вас есть вся информация о клиенте, история всех взаимоотношений с ним, пункты, которые надо обсудить и достоверные материалы по каждому из них — практически предрешены. К сожалению, в моей практике подготовленных встреч — единицы, в большинстве подготовка сводится к мысли «надо встретиться и поговорить», а не к «надо обсудить конкретные пункты и подготовить по ним решение или информацию для принятия решения». Да что там говорить, даже элементарная повестка встречи, рассылаемая в срок, достаточный для ознакомления и подготовки, применяется отнюдь не во всех компаниях.

Все эти риски минимизируются в проектной деятельности наличием и использованием (специально разделяю эти два пункта) проектной методики, но даже в случае ее отсутствия, рекомендую потратить один вечер в тишине, составляя перечень того, что надо не забыть.

Что касается подготовки яхты к переходу — существуют выстраданные списки пунктов, необходимых к проверке и выполнению. Метаться по яхте, думая о том, что ещё нужно «не забыть» находясь перед перспективой ближайшие десять суток провести без какой либо связи и земли на горизонте — плохая практика. Для понимания серьезности вопроса можно привести интересные цифры — спасательная операция по эвакуации океанской экспедиции Кон-тики 2 заняла около суток. Именно столько времени понадобилось ближайшему кораблю для того, чтобы прибыть к месту инцидента.

В менеджменте, конечно, у вас будет мобильная связь и возможность запросить подмоги, если что-то не проверили по списку перед началом проекта. Однако, если вспомнить о сроках принятия решений в крупных корпорациях, ваше положение гораздо хуже. Именно поэтому, до отбытия, вам нужно сосредоточиться на списке «что нужно сделать», и первым в этом списке должно быть:

4. Знакомство с командой


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

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

5. Определение целей и задач


Думаю, что не менее 50% успеха проекта определяется тем, насколько участники одинаково понимают цели, результаты, и какие задачи должны быть выполнены для их достижения. О том же толкуют и все практики проектного управления — в них планирование по праву занимает существенную часть. Тем не менее, создать план понятный, достаточно детальный и при этом обозримый — целое искусство. Равно как и искусство сделать такой план, который даже при невыполнении ключевых показателей и не достижении результатов может быть преподнесен как выполненный. Мы не будем углубляться не в одну из этих областей, так как вы и так наверняка неоднократно слышали замечательные формулировки «разработан процесс», «ведется выполнение», «работает в штатном режиме» и иные, аналогичные им. Если же говорить про правильное планирование, с декомпозицией измеримых результатов — то это слишком глубокая для нашего повествования тема.

Применительно к нашей ситуации, отметим что «дойти до точки В» и «стараться не повредить яхту» — существенно отличающиеся цели. И если цель — «стараться не повредить» — не озвучена, то у экипажа будет недоумение, почему при свежем ветре капитан отдает команду снять паруса и идти под двигателем, расходуя и так недостаточный запас топлива (что в нашем примере означало еще и расход денег экипажа).

Чтобы снизить не только недоумение, но и следующее за ним сопротивление, необходимо чтобы было проведено:

6. Информирование о правилах исполнения и контроль их понимания


На яхте этот пункт носит критический характер, поскольку «правила исполнения » в этом случае включает правила поведения и затрагивает почти все области жизни на борту. Представьте что 10 мужчин находятся на площади в 30-40 м2 на протяжении нескольких дней или недель. И эта площадь включает туалеты, кровати и кухню. При этом они говорят на разных языках (часть поляков не говорила на английском), у них разные традиции в быте, еде, отправлении естественных надобностей (это тоже важно). Хорошо, если они уже не первый раз сталкиваются с такой ситуацией и имеют представление об интернациональных стандартах. Иначе — горе, сравнимое с 10, а не с двумя хозяйками на одной кухне.

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

В бизнесе, к счастью, люди не столь погружены во взаимодействие, а типовые ситуации и вопросы, как правило, описаны в законах, должностных инструкциях, кадровых политиках и иных регламентирующих документах компании. Тем не менее, это всегда источник постоянных вопросов как к HR службе, так и к руководителям. «Где моя премия?», «Почему Вася уходит раньше?», «Почему я за всеми доделывать должен?» — уверен, вы сами без труда продолжите этот список как вопросами от своих подчиненных, так и своими личными. Возникают они потому, что не все знают, где посмотреть «правила исполнения», «правила игры», или туда не заглядывают.

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

Поэтому, разъясняя правила, не забудьте про пункт:

7. Оценка рисков


Строго говоря, риски вашего проекта или предприятия связаны не только с неисполнением правил. Они могут быть связаны и с отсутствием правил, или их недостаточным пониманием, или вообще с внешней средой. К сожалению, частой практикой в бизнесе и проектном управлении является «наступит – тогда будем устранять». Имеющиеся же положительные практики зачастую заканчиваются, только начавшись, в момент озвучивания бюджета превентивных мероприятий. Даже в отношении критических для бизнеса подсистем, к которым в наш высокотехнологический век относится ИТ, отнюдь не все бизнесы имеют «план В».

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

Один из этих рисков, хорошо известный большинству яхтенных капитанов, исполнился и у нас. Когда на яхте несколько гальюнов, а на кухне царит нездоровая анархия, посуду моют проточной пресной водой, и если никаких правил (смотри п.6) в этой области не озвучено, то не стоит удивляться тому, что вода кончается к середине путешествия. Хорошо, если при этом у вас есть резервный бак и (или) отдельные запасы питьевой воды, и плохо если нет. У нас, к счастью, резервный бак был. Тем не менее, вторую половину маршрута все гальюны были отключены от воды, а посуду мыли только при помощи ручной помпы (что автоматически в разы снижает расход).

8. Создание плана коммуникаций


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

На яхте же роль описанных и озвученных правил коммуникации исключительно прозрачна и понятна. Так как капитан, как бы ему не хотелось, не может управлять процессом в режиме 24х7, а строго говоря, и не должен, так как однотипный процесс целесообразнее контролировать по отклонениям, то на каждый нештатный случай должны быть предусмотрены коммуникации. Например, необходимо определить коммуникации для ночного расхождения с другим судном, или для случая приближения к сплошной облачности (приближение атмосферного фронта). Если не предусмотреть такие ситуации, и не проинформировать экипаж о правилах оповещения, то можно хлебнуть горя, что и произошло с нами.

Мы прошли к атмосферному фронту под всеми парусами, так как капитан не проинструктировал экипаж и вахту о необходимом оповещении его в этой ситуации для принятия решения о снятии паруса, и не определил право вахты самостоятельно снимать паруса. Результат – брочинг, хорошо, что без последствий. В плохом сценарии – поломанная мачта, порванные паруса, эвакуация экипажа с середины океана и шестизначная сумма убытка (в евро).

9. Регулярный мониторинг исполнения задач и состояния рисков


Этот пункт не вызовет вопросов не у одного менеджера, но взятый в отрыве от всех остальных он не столь эффективен. Весьма продуктивно, когда задачи, с которыми работает этот процесс, являются измеримыми (а лучше SMART), и имеют четко определенного ответственного. Если же этого не удалось достичь на этапе планирования, вас могут ждать неприятные сюрпризы.

Незнание нашим капитаном этого подхода в полном объеме стало понятно уже в самом конце путешествия, при подходе к Португалии, когда зазвучали команды вроде «Уберитесь на камбузе», «Отдайте кормовые». Несложно заметить, что такие команды брошенные в воздух останутся без должного исполнения, так как ситуация когда 9 человек (экипаж минус капитан) будут убираться на камбузе или бросятся к кормовому (какому, правому или левому?) концу – достаточно комична. С последним, правда, есть еще другая интересная особенность и она называется:

10. Внесение корректировок


Этот пункт также описан в хорошей яхтенной практике, и его также не применял наш капитан. Зачастую, ситуация меняется, и меняется динамично. Тогда наряду с заданием общих правил поведения (которые должны быть разъяснены заранее и поняты, опять смотрим пункт 6), должны своевременно подаваться команды об изменении ситуации и необходимого алгоритма действий.

Швартовка яхты – традиционно нервная и неприятная для капитана процедура, так как именно в этот момент легко повредить как свою яхту, так и чужие, стоимость которых может измеряться миллионами долларов. Именно для этой процедуры экипаж инструктируется заранее, распределяются обязанности и определяется система коммуникаций (определяется, кто и что должен говорить и делать). Команды при изменении условий швартовки должны быть громкие, четкие, понимание команд фиксируется членом экипажа повторением команды с добавлением слова «Принял!».

Так легко представить эту команду на море, так сложно в менеджменте. Зачастую нам не хочется отменять свое распоряжение или приказ, так как мы видим в этом угрозу своей репутации. Поверьте, гораздо лучше отреагировать своевременно и четко, пусть и в противоречии с предыдущими указаниями, чем продолжать мучать сотрудника очевидно бесполезной работой. Как правило, неявное все равно становится явным и ваша репутация в этот момент страдает гораздо больше, чем при своевременном распоряжении. И конечно, не забывайте контролировать понимание.

11. Приемка результата


Это самый приятный момент в управлении, и немного грустный в моем яхтенном путешествии, так как для меня он означал перерыв на значительный срок. Не знаю, менталитет тут играет роль или что-то еще, но мне редко попадались руководители, которые при завершении проекта или крупного блока работ благодарят сотрудников и тем более делают разбор выполненных работ и достигнутых результатов. Да что скрывать, я и сам не сильно склонен к похвале. Тем не менее, это очень действенный инструмент, как для мотивации вашей команды, так и для выявления новых целей собственного развития. Например, целей по выполнению в следующем путешествии или следующем проекте всех пунктов, разобранных выше.

Давайте, повторим:


1. Согласование терминологии – обмениваясь информацией, понимать смысл слов одинаково
2. Согласование условий – условия вашего участия надо обговаривать заранее в мельчайших деталях, или заносить оставшиеся невыясненными моменты в ваши риски
3. Подготовка к проекту – заранее подготовить чек лист того, что нужно будет сделать на этапе подготовки
4. Знакомство с командой – узнать о команде все, что можно. Лично познакомиться с участниками и выстроить регулярные личные коммуникации
5. Определение целей и задач – определить и довести до участников цель и задачи проекта, объяснить степень участия каждого. Стараться соблюдать SMART
6. Информирование о правилах исполнения и контроль их понимания – разъяснить и проконтролировать понимание применяемой модели управления и требований к выполнению задач
7. Оценка рисков – выявить риски, разработать и предпринять превентивные меры (в соответствии с политикой управления рисками). В отношении важнейших из оставшихся, иметь план корректировочных действий на случай их исполнения
8. Создание плана коммуникаций – обеспечить понимание каждого участника, кому и что ему необходимо сообщать
9. Регулярный мониторинг исполнения задач и состояния рисков – дополнить штатный процесс управления критериями, исключающими возможность ошибочного толкования результатов. Стараться избегать расплывчатых и неизмеримых формулировок, они сделают этот процесс неэффективным
10. Внесение корректировок – не бояться перечить самому себе. «Не меняется только дурак и покойник». Изменение, впрочем, также надо оценить по SMART
11. Приемка результата – проанализировать и разобрать результаты проекта. Провести итоговую встречу с участниками проекта, обеспечить обратную связь для всех участников.

Комментарии (15)


  1. fivehouse
    23.10.2017 11:07

    Очень понравилась статья. Добавить бы что должен быть план действий и каждый должен знать свою роль.


    1. Beloborodov_A Автор
      23.10.2017 13:12

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


  1. dimkss
    23.10.2017 11:48

    Статья слишком общая. Заменить яхту практически любым другим проектом — будет все то же.
    Блин.

    >> Это около 1000 морских миль, 10 дней открытого океана, без возможности сойти на берег.
    И что, все самое интересное это выводы типа: коммуникация, риски, мониторинг, корректировка, правила, цели и задачи?


    1. i_user
      23.10.2017 12:34

      По личному опыту складывается ровно такое же ощущение:
      Проектный менеджмент — это очевидные, общие и довольно прописные истины.
      Проблема в том, что для каждого практического кейса — фраз, описывающих решение оной — несколько десятков. Рабочих из них около десятка, уместных 1-2. Поэтому хорошие статьи по проектному менеджменту очень часто смотрятся как исповедь капитана очевидность. Тем не менее таковыми не являются.
      Воспринимайте статью как очевидное перечисление очевидных областей с тем чтобы вы проделали неочевидное для своего проекта — и прошлись по этим областям чтобы понять — закрыты ли они у вас осознанно или «сложились исторически и не очень выгодно».


    1. Beloborodov_A Автор
      23.10.2017 13:19

      Да, статья общая. Из моего опыта, даже приведенные элементарные правила не соблюдаются почти никогда.
      Мне показалась интересной возможность показать как правила, используемые в ИТ работают в других, казалось бы совершенно чуждых высоким технологиям областях. Более того, именно там их необходимость становится очевидной.
      Если статья понравится, буду продолжать подробнее рассказывать что делать в ИТ проектах по каждому пункту. Опыт позволяет, время пока есть.


      1. PM_Pro
        24.10.2017 12:15

        Так собственно никакой привязке к ИТ в статье нет. Правила проектного менеджмента везде одни и те же, тут вон одни товарищи аэропорт по аджайлу строили например.


    1. XopHeT
      23.10.2017 13:27

      Статья слишком общая. Заменить яхту практически любым другим проектом — будет все то же.

      Похоже на типичный треннинг. Информации много. Она полезна.
      И те, кто «в теме» понимают про себя «да, да, я тоже так делаю» или «а, вот чего я не делаю».
      Те, кто не «в теме» просто пропускают мимо ушей большую часть информации.


      1. Beloborodov_A Автор
        23.10.2017 13:47

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


    1. Stochkas
      23.10.2017 17:09

      замыленная статья, както так


  1. Dmitry_7
    23.10.2017 13:42

    Можно посмотреть фильм Баунти. Там было много чего нарушено, однако, капитан был повышен в должности. В реальном мире все не так, как в выдумках экипажа


    1. Beloborodov_A Автор
      23.10.2017 13:57

      Да, в моем примере мы тоже дошли до Португалии. Провал руководителя проекта не всегда означает провал проекта. Хорошая команда может вытянуть проект, даже если руководитель — так себе. Это тоже, хоть и неявно, следует из статьи.


  1. Kurilova
    23.10.2017 14:18

    Очень грамотно сформулированная и структурированная статья, на мой взгляд. Конечно, предыдущие комментаторы правы в том, что вроде как эти правила нам всем известны. Но! Они действительно НЕ выполняются. А дальше происходит следующее — разжевывая необходимость их выполнения генерируешь много мусора, наворачиваешь понятия в клубок, у самого уже башка трещит и как просто объяснить прописные истины команде в какой-то момент уже не знаешь — закопался в поисках определения очевидного. Но теперь у меня есть отличный способ — я просто буду кидать ссылку на эту статью :) Тут всё коротко, ясно, по делу и с очень, очень хорошим примером-аналогией про яхту. Спасибо!


  1. rumatavz
    23.10.2017 16:58

    У меня яхтенный комментарий. Честно говоря от прочтения статьи душа в пятки ушла от страха, потому что в худшем случае не убыток, а смерть. А при таком бардаке…

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

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

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

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

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

    Для воды аналогично — думаю для опытного капитана это вообще не вопрос что делать с водой. Мене опытным нужно попроектировать(прогнать в уме все плаванье) и только потом! выявлять риски.


    1. Beloborodov_A Автор
      23.10.2017 17:55
      -1

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

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


  1. ghost404
    26.10.2017 09:43

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


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


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

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


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

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


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


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

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


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


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

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


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


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


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


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

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


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

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


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

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


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


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