Вам приходилось быть свидетелем общения в стиле:
– Это надо сделать методом А
– Нет, так это делать не в коем случае нельзя, а надо методом В
– Ты меня не слушаешь, надо делать методом А иначе будет жопа
– …
Как долго могут продолжаться подобные дебаты? Час или два? А может дольше? Обычно в таком общении собеседники лишь укрепляются в собственном мнении и в неправоте оппонента. Чем дольше человек отстаивает, что его мнение самое верное, тем больше он находит доказательств этому. Чем больше давят, тем больше сопротивляется.
Действию всегда есть равное и противоположное противодействие
Третий закон Ньютона
Перефразируя, для коммуникации, один из законов Ньютона получим – упорство в отстаивании собственной позиции равно силе попыток эту позицию изменить.
Первое следствие этого закона будет: самое результативное, что можно сделать в споре, это не спорить.
Второе следствие: самое разумное в конфликтной ситуации – согласиться с собеседником. А если собеседник, на наш взгляд, ошибается? А если цена ошибки высока, и надо его убедить?
Любой повар на флоте тебя накормит, если ты дашь ему возможность рассказать, какая ты скотина.
Р. Хайнлайн «Приключения астронавигатора Джонса»
В одной из риторических школ был популярен метод, который использовал согласие с собеседником, как один из шагов доказательства. Метод получил название Сократического диалога – по имени его создателя. Принцип был прост и основан на трех шагах.
Первый шаг (задача: найти, с чем можно согласиться)
Вам высказали замечание, найдите, с чем можно согласиться. Даже в самом простом предложении скрыта ни одна мысль, а множество. Мы можем выделить то, что считаем действительно правдивым, и согласиться. В этом случае мы и душою не покривим, и общение наше начнется не с конфронтации, а с согласия.
Ты опоздал на митинг– Да, я слегка задержался.
Это должно быть сделано в первую очередь – Конечно, это одно из важнейших дел.
Заполни таймрепорт – Да, уже надо это сделать.
Когда мы согласились, переходим ко второму шагу:
Второй шаг (задача: выразить сомнения по поводу слабого аргумента)
Тут нашей задачей будет слегка поставить под сомнение, то, что мы не считаем, истинным.И только после того, как наш партнер убедиться, что мы готовы соглашаться с ним в принципе и что мы в состоянии трезво оценивать значимость и ценность аргументов, мы можем переходить к опровержению тех его аргументов, которые кажутся нам неверными.
Третий шаг (переходим к опровержению)
Вот тут уже начинаем доказывать или отстаивать свою точку зрения.
В целом алгоритм действий получается приблизительно следующий:
Для получения результата, фразы можно подставлять любые, лишь бы они соответствовали смыслу своего блока.
А теперь то же самое но в виде псевдокода:
static void СократическийДиалог()
{
var обвинение = слушаемОбвинителя();
// "Ты опять завалил билд, и это уже не первый раз
// за неделю!"// Признаем правоту собеседника (скрытая похвала)
говорим("Ты прав");// Анализируем ситуацию
// Соглашаемся с тем пунтом обвинения, с которым
// легко согласиться
if(яВиноватСильно() || обвинительАвторитарен())
{ // авторитарному обвинителю нужно признание
говорим("я завалил билд");
}
else
{ // факт падения есть, но от обвинения уходим
говорим("билд опять лежит");
}// Сомневаемся в слабом пункте обвинения
говорим("Хорошо, что это впервые за две недели");
// либо "Возможно, в этом виноват я"// Даем объяснение или опровержение:
говорим("Похоже, кто-то поменял конфиг сервера");
// либо "Это опять тот плавающий баг"
// либо "Джон закоммитил одновременно со мной"// Переходим к действию
говорим("Сейчас посмотрю");
// либо "Мне посмотреть, или сначала закончить текущий таск?"
}
* This source code was highlighted with Source Code Highlighter.
[poll id=”2″]
К сожалению, представленные в статье варианты относятся к одному и тому же типу — к оправданиям. Суть же проблемы растет из неорганизованной ответственности:
—Ты опять завалил билд. (это твоя обязанность вливать изменения в мастер-ветку)
Варианты ответов:
— У меня нет возможности вливать изменения в мастер-ветку, из которой делаются билды. (Есть другой человек, чья обязанность это делать, и ТЫ НЕ ПРАВ, обвиняя меня в этой проблеме)
— Да, это моя проблема, я ответственен за контроль работоспособности мастер-ветки. (Ты прав, это моя вина)
И если это действительно твоя вина — нужно не оправдываться, а выполнять свою работу качественней. Оправдания в любом случае — тупиковый вариант развития событий.
Оправдания это первая реакция, и мы совершенно не в курсе, насколько они обьективны. Возможно человек прав и защищается, возможно он неправ и отмазывается. Но в зависимости от склада характера участников – разговор может быть просто неконструктивен и в том и в другом случае.
Здесь ведется речь не о правоте участников, а о способе вести разговор конструктивно. И только.
Оправдания – не конструктивны. Они мешают найти действительно ответственных за проблему, «размазывая» вину на обстоятельство, других работников, фазы луны.
Сами оправдания – неконструктивны. Но это инструмент, не более.
Инструмент чего? «Отмазывания» исполнителя от своих ошибок? Ну, если цель статьи «Как правильно оправдаться, что бы начальник не наказал сильно» — тогда да, вполне себе инструмент. Если же целью было «Найти способ выйти на конструктивный диалог» — то оправдания ни разу не подходят.
Сегодня был вынужден сделать замечание работнику за срыв сроков. (Не в первый раз, к сожалению.) От сказал — «да, я не прав, я сорвал сроки». А проблема не приблизилась к конструктивному решению, потому что надо не оправдываться, а выполнять запланированную работу — вовремя. Обсуждать в этой ситуации — нечего, на самом деле, надо просто выставлять новые сроки, и снимать процент премии за простой.
Вы рассматриваете ситуацию простую как кирпич – когда исполнитель
а) Действительно неправ
б) Неправ строго один, а не в составе команды.
в) У него нет причин которые вынудили его к неверным действиям, скажем, срыв сроков поставок, или отключение электричества во время работы.
Да, если это все вот так вот просто и однозначно – разговоры говорить не о чем. Только так редко бывает.
Как руководитель разработкой я вам скажу: если у вас ответственна за задачу «команда» — это значит ответственных у вас вообще нет. На каждую под-задачу должен быть ровно один ответственный в один момент времени — это азбука управления коллективом.
Если у него отключат электричество на 3 дня — я об этом узнаю задолго до этого разговора. Если отключение электричества на полчаса привело к срыву сроков задания, на которое выделено 3 дня — это срыв сроков. Форс-мажоры бывают. Но если форс-мажор произошел за 5 минут до окончания срока — это неправда. Если форс-мажор произошел, менеджер это отметит, и сроки сдвинутся на адекватное время.
Если у него «срыв сроков поставок» — я приду не к нему, а к тому, кто в плане проекта стоит ответственным за поставки. И увижу это просто по незакрытому заданию у ответственного за поставки в управлению проектом.
Поэтому да, нормальный поток разработки всегда однозначно определяет одного ответственного за срыв человека. И все ситуации в итоге как раз «простые как кирпич»
Простите, а что вы сейчас пытаетесь мне доказать? Что если ответственность строго разделена и виновный всегда известен – жить проще? Так и есть. Увы, не все рабочие ситуации к этому сводятся.
Мне бы хотелось услышать от вас пример «рабочей ситуации» которая не сводится однозначно к одному ответственному.
Например – вам в суппорт дается проект, который начат не вами, при начальной инспекции кода вы приняли решение что проект в удовлетворительном состоянии и. Ваш разработчик же считает что архитектура не выдерживает критики и нужно делать рефакторинг. Вы принимаете решение начинать суппорт на имеющейся архитектуре. Далее, через месяц-два ваш разработчик совершает крупную ошибку, неправильно избрав решение по фиксу бага. Его аргументы – я предупреждал что архитектура никуда не годиться, сейчас мы видим проблему.
Я, как руководитель, не буду проводить инспекцию кода. Нельзя заниматься той работой, которая не входит в круг обязанностей. Это будут делать те, кому этот проект поддерживать. И я буду принимать свое решение о поддержке проекта на основании заключения этого технического специалиста. И в случае провала ответственность за принятое решение несет только он.
Поэтому, я повторюсь, оправдания — абсолютно не конструктивная и бесполезная деятельность в нормальном рабочем процессе.
Хорошо, вы как руководитель, не инспектировали код. К вам пришел ваш разработчик и сказал что код в ужасном состоянии. И сказал что ему нужно месяц на то чтоб все переписать. У вас нет месяца, вы сказали чтоб он начинал работу по грязному коду. Через месяц у него вылазит проблема. Если вы считаете что это только его проблема – это не так, поскольку вы приказали ему работать "по грязному" коду. С другой стороны, если считать что это только ваша проблема – то разработчик будет теперь для гарантии каждый код обьявлять плохим, чтоб перевести ответственность на вас.
И что значит «совершает крупную ошибку»? Совершил ошибку — откатили коммиты до нужного места, делай снова. Что значит «рефакторинг архитектуры»? Рефакторинг бывает у кода. Это собственно говоря, и есть процесс обычного потока разработки и сопровождения ПО. Рефакторинг как отдельный процесс в проекте — бред. А под «рефакторингом архитектуры» вы очевидно понимаете реинжиниринг, которому все равно предшествует рефакторинг.
Совершает ошибку – значит совершает ошибку. Выбирает неверное решение, которое может затронуть не только его и его код.
Коммиты. Откатываются. До нужного. Места. Простите, но по-моему, вы очень далеки от реалий реальной командной разработки. Поэтому дальнейшую дискуссию считаю нецелесообразной. Всяческих благ вам.
Время тоже откатывается до нужного места?
Да вы батенька бооольшой оптимист.
Навскиду несколько примеров, когда нету одного человека ответственного за проблему
а) К вам приходит ваш босс и говорит – Вася, очень нужно этот проект добить в 1.5 месяца, вместо 2. Вопрос жизни и смерти.
Вы идете к программистам, долго совещаетесь, решаете, что вероятность это сделать 80%, сообщаете это босу. А потом проект таки выходит 2 месяца (причем затягивает не один программист, а равномерно все).
Кто виноват? Босс, вы, программисты?
б) Продукт менеджеры предложили две новые фичи. Обе фичи были сделаны и только к концу тестирования, кому-то в голову пришла идея, что эти фичи могут конфликтовать в каком-то редком, но как оказывается важном случае.
Кто виноват – продукт менеджеры, вы, QA, программист реализовавший фичу 1 или программист реализовавший фичу 2?
в) Босс у вас с проекта забирают человека на другой более важный проект. Вы пытаетесь оценить как это может повлиять на сроки и сообщеете, что релиз сместиться на 1 месяц. Релиз затягивается на дополнительные 2 недели (поверх оцененого вами месяца).
Кто виноват? Босс, вы, программисты?
От безалаберного начальства тоже надо уходить, как и надо увольнять безответственных сотрудников. Если вы не цените сами свой труд — никто другой ценить его тоже не будет.
Я начинал работу в крупных гос. учреждениях, где есть этот подход, да «через месяц надо сдать проект и ниибет», и где в результате получается какая-то полурабочая хрень. Потом я понял, что если босс устраивает истерики, и его нужно принудительно выводить на конструктив — это плохой босс, и от него надо уходить. Если босс не в состоянии оценить риски по срокам, и нести за них ответственность за принятое решение — а снятие программиста с проекта это компроментация рисков, да, от него надо уходить.
А в приведенных примерах:
а) Виноват я — неверно оценил сроки и риски (моя работа)
б) Нерабочая ситуация. Менеджеры не имеют права предлагать НИКАКИХ фич в текущий релиз по определению, после начала релиз-ветки все новые фичи сроками ставятся после релиза.
в) Виноват босс. И снятие человека с проекта можно просчитать в том же ПО ведения проекта, поскольку скорость работы его известна, и показать боссу, и уведомить его об этом — моя обязанность.
Оправдания не конструктивны. Проблема только в том что понятие оправдание весьма размыто. Я лично понимаю под оправданием позицию в которой человек полностью отказывается от своей ответственности, то есть ведет себя как ребенок (Я подошел, а оно упало, я ничего не делал и т.д.). Как я понимаю конструктивность, она начинается когда оба собеседника готовы мыслить трезво и без сильных эмоций (таких как гнев, презрение, уверенность в собственной правоте, страх потерять авторитет и т.д.). Снизить интенсивность таких эмоций позволяет согласие с собеседником. В случае если подчиненный боится признать свою вину, признание его невиновности быстрее приведет его в рабочее конструктивное состояние, в случае если начальник вне себя от злости признание своей вины и его правоты быстрее вернет ему способность критически мыслить. С этой точки зрения конструктивно потратить 3 минуты для создания рабочей атмосферы, чем час доказывать чья это вина.
На самом деле, как показывает практика, начальника нельзя пускать непосредственно к программистам вообще — общаться с ним должен тимлид, и шишки на себя собирать должен только он.
Я согласен – статья по-моему вкорне странная. Вначале был пример общего спора, когда обе стороны не приводили аргументов своих методов, а затем описали "алгоритм" спора на примере оправдания.
Если что-то на работе ломается, то виноваты все. И тот, кто зачекинил код, и тот кто не протестировал / не проинспектировал / проконтролировал. И первой реакцией всех должно быть разобраться, как это исправить побыстрее, а не искать кто виноват.
Тем более странными кажутся рассуждения типа "Я в этом сильно виноват?". Во-первых, разные люди на это будут отвечать по-разному. Любой хороший специалист не будет отмазываться и возьмет ответственность за себя. Если чинить не ему – то постарается помочь тому, кто сможет починить, при этом не переводя стрелки.
Вообще, если падение билда – большая трагедия, то нужно пересматривать процессы в организации. Такие вещи всегда можно автоматизировать (откат последних изменений, письмо авторам последних изменений и пр). Если починить билд стоит каких-то 15 минут – тут и оправдываться нечего. Похоже, что проблема с оправданиями может встать только в дебильных компаниях, когда все организовано неэффективно, и когда разработчики наказываются за такие элементарные вещи. Это бред, и искать этому решение в "сократических диалогах" – тоже.
Я хочу отделить тут два направления.
1. Про билды: этой осенью у нас был крупный проект, на котором тесты бегали более двух часов. С учетом продакшена, распределенной команды >20 чел и т.д. падение билда – тяжелая ситуация. Идеи апгрейда сервера и сокращения/оптимизации тестов – там все уже вылизано. Оптимизация даже вдвое ситуацию не улучшит.
2. Про сам диалог, и это – важнее: с помощью нескольких простых слов можно упростить отношения в команде в первые секунды, когда еще нет данных для конструктивных действий. У начальника может и есть – а у нас еще нет.
Я стараюсь использовать оба пути – и технический, и коммуникационный. Жизнь проще, когда идешь на двух ногах :)
Уведомление: Блоксхемы или псевдокод? | Психология в IT
Хорошая статья, идея с псевдокодом и блок-схемой мне очень понравилось, хотя, наверное, рисовать и то и другое очень утомительно, я проголосовал "и то и другое", но думаю, можно сэкономить на том, что отнимает больше времени
Думаю так и будет.
Псевдокод убивает наповал
Молодец!
Спасибо… Это было озарение :)
Псевдокод и блоксхемы оба хороши. Но не для всего. В данной статье, на мой взгляд, лучше читается блоксхема. Но, если, "алгоритм" будет раза два сложнее с циклами и прочим, боюсь блоксхема будет хорошо читаться только с листа А1, но не с экрана.
Открою секрет — лучше всего читается хорошо написанный текст. ;) Остальное больше баловство, для развлечения. Но и нотка юмора — это неплохо, да.
Нету у вас месяца. Потому что проект вы получили после конкурентной борьбы с другими командами, где вас давили по деньгам и по срокам.
Я рад что у вас все и всегда получается, и полагаю, что вам неинтересно читать этот блог. У вас и так все хорошо.
Жуть.
По шаблончику напиливать себе мозги, сурьезная задача.
конкретно в этом примере блок схема понравилась больше, но это ничего не значит :) поэтому я решил не голосовать :)
Для простых вещей ее хватит, для сложных – посмотрим.
Голосую за MindMap и против блок-схемы и псевдо-кода.
Тоже идея на подумать, как ветвление в MindMap отобразить.
Хорошая статья. Спасибо что написали.
Псевдо-код прикольный, лично для меня, блок-схема более читаема, хотя голосовал за оба подхода.
Уведомление: Фичи Драматического треугольника | Психология в IT