Эффективная команда

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

А нужны ли нам вообще команды?

Работа в одиночку


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

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

При работе в команде все не так радужно, не так ли? Внезапно, вам приходится посещать совещания. Вам приходится участвовать в различных дискуссиях на технические темы (что еще ничего), а также на другие неинтересные и скучные темы. Вам приходится отвечать на вопросы, хотя бы из вежливости, а также частенько делать вещи, с которыми вы совершенно несогласны.

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

Итак, команда помогает решать сложные проблемы, но и несет с собой дополнительную нагрузку.

Работа в команде


Эффективная команда снижает эту дополнительную нагрузку, сводит ее к минимуму, и позволяет людям концентрироваться на важных вещях, а именно на решении проблем и разработке. Если посмотреть на команду с этой точки зрения, то можно играючи выделить много хороших, годных практик для повышения эффективности команды:
  • Меньше людей. Маленькие команды имеют меньшую нагрузку на процесс.
  • Один язык. Все должны понимать друг друга максимально быстро. Вот почему оффшорные команды всегда имеют дополнительные проблемы.
  • Меньше совещаний. Любое совещание, которое не решает конкретную проблему, должно быть отменено. К примеру, статус-репорт митинги — это совершенно идиотская практика.
  • Изоляция команды. Одна команды — одна комната. В одной комнате не должно быть 2 команды, которые занимаются разными вещами.
  • Быстрые коммуникационные каналы. Вообще цель — это минимум общения. Так что если вам необходимо что-то обсудить, лучше всего это делать наиболее быстро, а значит лично, и желательно возле большой белой доски.

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

Доверие


Невозможно создать команду без доверия. А почему, собственно? Да просто-напросто доверие уменьшает необходимость провести очередное совещание или обсуждение. Доверие сокращает время на коммуникацию и позволяет решать проблемы быстрее.

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

Если вы поглядите на такую команду в действии, вас поразят тупые решения и глупые практики. Цель любого человека в такой команды — прикрыть собственную задницу спину.

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

Доверие экономит время и позволяет уделять внимание реальной работе, а не политике.

Страсть


Мы все видели людей с потухшим взором. Мы все видели скучные полумертвые команды, где работают с 9 до 18 и не могут дождаться конца рабочего дня. Никто не хочеть работать в таком месте. На удивление, многие работают. Я лично не понимаю, почему люди занимаются подобной ерундой. Я не могу принять аргументацию на уровне «стабильность», «зарплата», «привычка». Я не могу работать в скучном месте над скучными проектами. Это скучно. Это неинтересно. Это бесполезно. Это угнетает и лишает перспективы.

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

Заключение


Классная команда разработчиков состоит из нескольких страстных, опытных профессионалов, которые доверяют друг другу. Они эффективно взаимодействуют друг с другом для решения проблем. И достигают звезд.
Taucraft Limited
43,00
Компания
Поделиться публикацией

Похожие публикации

Комментарии 26

    +4
    Конечно, вы можете разговаривать сами с собой, но если это происходит слишком часто, вам также нужна медицинская помощь.
    Всё, ушел в больничку. Всегда при возникновении какой-либо проблемы обговариваю её сам с собой. Так решение находится быстрее.
    Вообще цель — это минимум общения
    С этим не согласен. Общение должно быть, и его должно быть много. Естественно не постоянно трещать о «левых» темах.
      +2
      главное не трещать о «левых» темах с самим собой, только по делу)
      0
      Мой взгляд на данную тематику — Я работаю один потому что:

      — Постоянно решая многочисленные проблемы в одиночку Я невероятно быстро учусь. И последующее возникновение подобных проблем меня не пугает.

      — Я отчитываюсь только перед собой и управляю моими действиями только Я, ну, может ещё жена… чуть-чуть.

      — Нет конфликтных вопросов относительно реализации.

      — Тестирование и оценка производится сторонними людьми и женой — результаты тестов гораздо объективней оценки товарищами по команде.

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

      — Страсть обеспечивается желанием, заработать денег на квартиру, а так же попутными желаниями жены.

      и самое главное…

      — Все деньги от реализации проекта достаются мне, ну, и чуть-чуть жене.
        +5
        В одиночку учиться очень сложно, поскольку придется затратить кучу времени на неправильные пути решения, в то время, как кто-то более опытный может сразу направить в верную сторону.
          0
          Хороший поинт. Но надо попасть в команду, где люди любят учить других людей. А еще лучше если там практикуется (хотя бы частично) парное программирование.
            +1
            Может быть сложно и бывает долго, зато надёжно. Раз на швабру наступишь, уже будешь аккуратней. А так когда тебе подсказывают где очередная швабра, это расслабляет. Замыкаться конечно не стоит, но всё же упор я бы делал на самообразование.
          +1
          Соглашусь с автором выше — общение должно быть. Разработка какого-то функционала должно обсуждаться. Митинги нужны, что бы так же выделить новые направления разработки.

          Что же касается статус-репортов, то их многие не любят — это факт. Но их можно избежать с введением системы управлением проектами, что мы менеджеры видели работу и отчитывались выше при этом не беспокоя рабочий процесс и программистов.
            0
            Видимо, надо пояснить.
            Минимум общения — значит минимум оверхеда.
            Конечно общение должно быть. Но надо очень аккуратно выбирать митинги и оценивать их целесообразность.
            И конечно, если есть сомнения в решении проблемы, надо их обсудить с кем-то.
            И конечно, если есть новые идеи, их тоже надо обсудить.
            Но. Не надо прибегать к товарищу, вырывать его из состояния потока, и рассказывать новую гениальную идею.
            Не надо также прибегать и сразу задавать вопрос, ответ на который знает гугл.
            И еще много чего не надо делать.
            Общение общению рознь.
              +1
              В целом всё правильно в статье. Но мне кажется, что главная проблема команд заключается в другом. Со слов ДеМарко, командой неверно называть группу людей, работающих над одной задачей или одним проектом, и я согласен. Команда это что-то большее. Так вот проблема в том, что команду нельзя построить «извне». Для этого нет рецепта. Более или менее известны условия, в которых появляются команды и рецепты для «убийства» команды.
                0
                Команда — тема болезненная. Для меня, например.
                  0
                  Расскажите, почему?
                    +1
                    Много надежды полагал на работу в команде. Опыт у меня пока небольшой, но основные проблемы, с которыми пришлось столкнуться — «культ Карго*» (по Макконнеллу) и банальное отсутствие интереса. Наименее я был в восторге от частых и затянутых собраний, которые проводились с целью «стимулирования команды», но на деле никакой полезной нагрузки не несли.

                    Но ведь негативный опыт тоже опыт. Теперь осознаю роль менеджмента и важность управления процессом разработки. Наверное, потому и стал интересоваться Agile после этого. :)

                    * «Культ Карго». Цитата из «Code Complete»:

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

                  Полностью с вами согласен! Но вот некоторые адепты Agile практик будут явно не в восторге.
                    0
                    Вы правы, это не восторгает.
                    +1
                    Надо не забывать что эффективная команда не возможна без сильного руководителя. А то получится как в басне лебедь рак и щука. Из этого и личного опыта есть еще один вывод, не советаю брать друзей в команду. Интересно услыщать мнение тех укого в команеде не один и не два человека…
                      0
                      Кстати, на эту тему. Частенько говорят, что команда должна быть self-organized. Особенно на это делают упор в Scrum. Я уверен, самоорганизация невозможно без хорошего лидера. Команда середнячков, конечно, тоже самоорганизуется, но она скорее будет делать упор на выживание, чем на достижения высоких целей. Так что нужен лидер и хотя бы пару сильных духом и скилом людей.
                        0
                        > Команда середнячков, конечно, тоже самоорганизуется, но она скорее будет делать упор на выживание, чем на достижения высоких целей.

                        С этим почти согласен, а с остальным в комментарии — нет. Лидер, это конечно, круто и полезно, но их крайне мало, как показывает практика. Команды просто вынуждены самоорганизовываться. А упора на выживание оказывается достаточно для многих проектов. В конце концов, не все пишут ПО для космических кораблей или превосходный стартап строят. Ну и вообще, словосочетание «высокие цели» можно понимать сильно по-разному.

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

                        В команде 14 человек, работаем вместе 9 лет. Дружим семьями (ну почти все).
                        +4
                        Мне кажется, в построении команды применим подход «Добавляй людей в команду, только если не можешь не добавить». Иначе в итоге получается, что тратишь время:
                        1. на то, чтобы придумать, какое задание дать человеку
                        2. на формальное описание, того что нужно сделать
                        3. на проверку сделанного

                        Т.е. больше времени уходит на разъяснения.
                          0
                          Очень хорошее правило. Мне нравится.
                          –5
                          Статья ни о чем.
                            –1
                            Эффективная команда = Креативные люди + Мотивация
                            Все остальное, что Вы написали — херь.
                            douglasernstylp.files.wordpress.com/2010/10/office_space.jpg
                              0
                              Не думаю, что твое утверждение каким-то образом противоречит статье, но безусловно является не полным.
                              Вот соберешь ты команду креативных, мотивированных студентов, которые не умеют программировать.
                              И че? За год сделаешь новый фейсбук?
                                0
                                Адекватность, желание учиться и минимальные навыки — требования по дефолту, посему не обсуждаются. Опыт приходит во время.

                                P.S. Цукерман сделал фейсбук, будучи студентом, и неумея программировать. Сделал по книжке для чайников. Дуров тоже осваивал php, пока писал вконтакт, стянув идею и дизайн у Цукермана.
                                  0
                                  исключения только подтверждают правило
                              0
                              Яндекс, Гугл, Эйпл это подтверждают. Один спец в поле воин сам с собой.

                              Что касается Цукерберга, так он просто не боялся экспериментировать и вовремя создал то, что давно люди ждали.

                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                              Самое читаемое