Навеяло. Готовил материал на cornflake.ru, и вдруг сделал статью собственного сочинения.

Командная работа, teamwork, работа в команде — одно из ключевых понятий в современном бизнесе. Сейчас все реализуют «проекты», и реализуют их именно с помощью «команд». Тема командной работы богата. И именно поэтому в этом материале мы не будем поверхностно освещать все ее аспекты, а остановимся на концепции построения эффективной обратной связи внутри команды.

Компания Fast Lane Ventures — нетипичный инвестор. В отличие от большинства бизнес-ангелов и портфельных инвесторов, принцип компании заключается в глубоком взаимодействии с управляемыми проектами, участии в их операционном управлении. Большинство нынешних стартапов компании были ею же и инициированы и, фактически, является «дочками» Fast Lane Ventures. Первое время они, как в инкубаторе, даже растут вместе — в бизнес-центре на Савёловской. Разумеется, такой большой коллектив должен жить по своим правилам и законам.



О том, как запустить бизнес-проект за 50 дней, как формируется, по каким принципам и законам живёт команда Fast Lane Ventures и какие требования предъявляются к менеджерам и руководителям — интервью HR-директора компании Ольги Гавриловой.

Хочу представить вам The team test от Swedish Armed Forces, командную флеш игру. Суть игры, казалось бы, проста, нужно выполнять различные задания на память и концентрацию.

За верно выполненное задание прибавляется время, за неверно выполненное — отнимается. Много таких игр есть на просторах интернета, в чем же изюминка спросите вы, а вот в чем: за успешное выполнение задания время додается не вам, а вашему партнеру по команде. Также ваше время целиком зависит от ваших партнеров. Вот такие вот простые правила, но игра очень увлекательна и необычна, дает почувствовать всю прелесть работы в команде.

Также можно создавать приватную ссылку и давать ее друзьям, чтобы поиграть вместе, а не со случайными партнерами. Выглядит это так:
team.forsvarsmakten.se/english/#/private/habr
Игра играется командой ровно из четырех человек, так что весь хабр по этому линку не поместится, уж извиняйте :)

Цель — это сильный внутренний мотиватор, согласно последним исследованиям в психологии, которые собрал и обобщил Ден Пинк. Работая с продуктовыми командами, я довольно часто сталкиваюсь с примерами, подтверждающими его доводы.

Отсутствие ясности на уровне видения продукта, четкого позиционирования на рынке, стратегии развития на 3-6 месяцев, давления срочности или ощущения конкурентной схватки — гасит скорость работы команды и личную вовлеченность ее участников.

Способность Владельца Продукта (роль Product Owner в терминологии SCRUM) воплощать видение продукта в своих словах и действиях, нельзя переоценить, когда мы говорим о командной разработке. Такая способность помогает команде работать сфокусированно (focus — одна из ценностей процесса SCRUM).

Фокус внимания меняет наше восприятие. Что бы лучше понять о чем это, попробуйте небольшой эксперимент. На протяжении дня держите в фокусе какую-то простую вещь, например, красный цвет. Обращайте внимание на все красное на улице и в офисе, думайте о красном в душе и лифте, найдите пару интересных фактов о самом цвете, или красных вещах. Уже к концу дня вы начнете воспринимать красный по-другому. Мужчины могут с удивлением обнаружить, что у красного есть оттенкиJ А на следующий день, вам могут приходить в голову “красные” мысли.

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

Ниже — 5 идей для Владельцев продукта о том, как усилить внутреннюю мотивацию и командную работу через видение.

Выход в свет новых моделей айфона повлек за собой появление понятных и не очень товаров, дополняющих его. Именно так возникла компания Mophie – первый бизнес предпринимателя Бэна Кауфмана (в 2005 он выпустил в свет кейс для iPhone, способный поддерживать заряд устройства). Через несколько лет Бэн понял, что потребитель/пользователь хочет не просто покупать, а изобретать самостоятельно. Так в 2009 году появилась его вторая компания Quirky. Бэн явно пытается возродить эпоху Генри Форда и Томаса Эдисона. Предлагаем выдержки из его интервью (перевод статьи Reinventing Invention: Quirky Lets You Be a Modern-Day Edison).

Самая значимая вещь, которая делает код в компании Google таким хорошим проста — code review (далее CR). Google не единственная компания, использующая CR. Всем известно, что это хорошая идея и множество разработчиков делают это. Но я не видел ни одной другой большой компании, в которой CR был бы так грамотно внедрен. В Google ни одна линия кода не уходит в production пока не получит позитивную оценку на CR.

Вы должны уделять внимание CR. Это непременное условие для разработки любого программного обеспечения на серьезном уровне. CR должен применяться не только для кода который уходит в production, но вообще для всего. Это не такая большая разница во времени как вы думаете, но разница в качестве получается огромна.

Что же вы получите от использования CR?

Предлагаю вашему вниманию перевод третьей части цикла статей «Becoming PHP professional».
Первая часть. «Недостающее звено»
Вторая часть. «Важность других людей»

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

Одна из проблем, с которыми приходится столкиваться, занимаясь настройкой окружения для разработчиков, с использованием Docker и Docker-compose, это вопрос о том, как сводить вместе несколько различных проектов. При условии, что все проекты, конечно же, имеют docker-compose.yml файл.



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

• Разработка низко связанных компонентов огромной системы. Где каждый проект, по сути, может являться отдельным самостоятельным приложением
• Подключение отдельных компонентов для тестирования. Вынесение mock-сервисов и тестов в отдельные контейнеры со своей логикой линковки и взаимодействия
• Внешнии, по отношению к проекту, системы, которые тем не менее 'живут' в docker среде

Предлагаю вашему вниманию перевод четвертой части цикла статей «Becoming PHP professional».

» Первая часть. «Недостающее звено»
» Вторая часть. «Важность других людей»
» Третья часть. «Работа в команде»

Ранее мы рассмотрели социальные аспекты работы в команде и ее плюсы и минусы. Однако, осталось еще много вещей, на которые стоит обратить внимание и многому научиться в работе с другими людьми.

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

Привет, Хабр!

На прошлой неделе мы выпустили новую версию Upsource 2017.1 — первое крупное обновление в этом году. В новую версию вошло множество новых функций, ряд улучшений по части юзабилити и не только. Теперь к вашим услугам кросс-проектный текстовый поиск, браузерные уведомления, отслеживание прогресса ревью, поддержка squash/rebase, новые воркфлоу, базовая поддержку GitLab и многое другое!

Посмотрите краткий обзор новой версии на английском языке:

«Талант выигрывает игры, а команда чемпионаты». Так однажды сказал Майкл Джордан и оказался прав. Любое успешное решение, будь то выигранный чемпионат или релиз нового продукта в IT команде, достигается усилиями каждого отдельного человека. С чего начинается командный путь к успеху?

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

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

Когда всякий результат дается кровью и потом, я стараюсь, чтобы «крови» было поменьше: избегаю того, что может быть неприятным, и стараюсь это предотвратить. Но если речь об обратной связи, сто́ит немножко потерпеть — в этом случае дискомфорт я люблю (ну или стараюсь любить).

Не поймите превратно: критика никогда не безболезненна. Это и беспокойство, и страх, и тревога.

«Ко мне станут относиться хуже?»
«Если мой код плох, не подумают ли, что я недостаточно умен?»
«О нет! Теперь все знают, что я в седьмом классе завалил тест по истории».

Не волнуйтесь — такая реакция совершенно естественна!

По словам Кимберли Лейтч, лицензированного клинического социального работника из компании Talkspace, получение обратной связи вызывает стрессовую реакцию — из-за суждения, которое часто исходит от человека, обладающего властными полномочиями.

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

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

Переведено в Alconost

Every manager knows what it is like to solve a problem. This is a daily activity for many people and it usually leads to the best outcomes. If you ignore or admit problems in your business, competitors can quickly pass you and your company will hang behind.

Any action that is aimed to solve a problem should identify this particular problem and its causes. Understanding the causes, you'll be able to set priorities and choose alternatives for the best solution, as well as directly implement this solution. The ability to solve internal and external problems timely and make responsible decisions is what managers should learn from the very start of their career. In this article, we’ll identify powerful problem-solving activities and analyze some effective techniques and exercises for teamwork.

The creation of design models as well as visualization of solutions is for some reason always a subject of great interest among all members of a productive team, be it a manager eager to master Sketch, or a developer who wants to make cool interfaces without the need to go to a designer. But we all know what happens when it comes to actually doing stuff.

My way

Hi, everybody!

My name is Anna and I work for an American company Scentbird NY as a product designer. Prior to that I was involved in developing flagship products in Alfa-Bank design team.

I was probably born under a lucky star but all my life I've been working with the developers who suggest the best product solutions, better than a lot of product managers and product owners. But anyway, my observation is that the earlier you involve developers into working on a particular task, the better off you are.

What you are about to read is actually a blueprint on how to conduct brainstorm sessions and generate not-so-obvious yet effective solutions, which are apparently really easy to reach and not that time-consuming.

Привет! Меня зовут Маша, я Scrum Master в ivi. Работаю с командами биллинга и веб-разработки и помогаю ребятам организовывать рабочие процессы так, чтобы не только эффективно достигать целей, которые ставит бизнес, но и получать удовольствие от того, что ты делаешь. В своих статьях хочу делиться опытом, как настраивать свою собственную работу и работу команд, если вы Scrum Master или Team Lead. А в этой статье давайте поговорим о важности культуры обратной связи.

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

Slack is the best inbox organizational tool in the market now. It is used by many huge companies ranging to average-sized and small companies as well. You can make and manage the business conversations through this app and can keep a record of them too.

Slack was initially released in August 2013, when there was not its single competitor out there in the market. Yes, there were many other messaging platforms but not for the business. Usually, the business websites give a boring idea of faded colors and take all the charm and drive away to use that website or app. But Slack did something different.

Договариваемся об эффективном и удобном общении при удалённой работе (и не только)

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

Но как же так, есть же книга DevOps Handbook, самый авторитетный источник. В ней есть целый раздел, посвященный мифам о DevOps, зачем писать статью? Ну, дело в том, что, на мой взгляд, эта книжка не только объясняет методологию, но и местами её продаёт.

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

1. DevOps к вам применим

Нет, DevOps подходит не всем. Этот миф идёт первым потому что некоторые отцы-основатели сами его исподволь продвигают.

Общался недавно с миддлом из команды разработки, которая состояла из 6-ти сеньоров и одного миддла. По словам миддла, расти в этой команде было очень сложно по ряду причин:

• отсутствие техлида. Формально техлид был. С очень высоким техническим уровнем. Но как руководитель, который мог заниматься ведением и развитием своей группы, он был полный ноль: не умел декомпозировать задачи, распределять их в соответствии с уровнем каждого члена, не занимался обучением группы, контроль деятельности группы осуществлялся в диктаторском режиме, софт скиллы отсутствовали и т.п.
• большой разрыв между скиллами миддла и сеньорами. То, что было непонятно миддлу, приходилось изучать на 95% самостоятельно, потому что у сеньоров не было времени и желания помогать миддлу в обучении, отсутствовало парное программирование (при этом код-ревью было отличным с технической точки зрения), в результате скорость работы миддла не удовлетворяла руководство, хотя качество его кода было высоким.
• отсутствие командного духа. Обстановка в группе была нездоровой, общение не партнерское или менторское, а с унижениями, насмешками, ошибки на этапе разработки были непростительны и т.п.

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

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

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

Переведено @middle_java