Эффективная работа над продуктом в распределенной командеКоманда

Программный комитет ещё не принял решения по этому докладу
Сергей Рябенко
SalesLyft

12 лет профессиональной разработки, в основном в продуктовых командах. Работал в LinguaLeo, уволился чтобы пилить свой стартап. Последние полтора года являюсь техническим менеджером в SalesLyft.
Увлечения: музыка, популярная психология.

Тезисы

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


Немного обо мне: 12 лет профессиональной разработки, из которых больше половины я работал вне офиса. Работал в компании LinguaLeo, учавствовал в ряде стартапов а которых уже никто не услышит, в том числе своем. Последние почти 2 года (на текущий момент) я руковожу разработкой компонентов SaaS платформ.


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

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

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

Одна частых ошибок - раздувание штата для ускорения работы - приводит к обратному эффекту. Я видел несколько ситуацию когда 3 разработчика работают эффективнее чем 12. Вместо масштабирования затрат стоит сперва хорошо наладить работу маленькой команды и только затем аккуратно добавлять новых разработчиков.

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

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

= Управление
Управлять людьми крайне неэффективно. Гораздо проще управлять потоками информации. Это не делается по счелчку пальцами и глупо пытаться объявить на общем звонке что со следующего понедельника мы делаем все по новому. Это непростой процесс, но это ключ к масштабируемости.
Каждый разработчик должен обладать достаточными знаниями о проекте чтобы принимать решения ежедневно с минимальным количеством коммуникаций. Продукт, как правило, имеет достаточно стабильный план развития, который нельзя менять каждый день.
Мотивировать людей слишком дорого, достаточно устранять факторы снижающие мотивацию. Пример с машиной: сделать имеющуюся машину мощнее/быстрее очень затратно, а с помощью своевременного ТО можно сохранить параметры близкие к начальным.
Нужно быть толерантным к ошибкам, но не толерантным к вредительству.

= Scrum или не Scrum?
Scrum это хороший фреймворк для построения очень и очень эффективного процесса разработки. Так же как автомобиль более эффективное средство передвижения на средние и дальние дистанции чем ходьба. Но для вождения нужны навыки, сноровка и внимательность. Попытка пользоваться прогрессом без должных навыков чревата печальными последствиями.
К сожалению в головах сейчас преимущественно каша из новомодных слов, которая, помноженная на невысокий уровень критического мышления, приводит к очень плачевным результатам.
Как бы то ни было Agile и Scrum далеко не единственные техники повышения эффективности работы.
Ответ прост: нужно использовать здравый смысл. В конце концов эффективная разработка была возможна задолго по появления самих терминов.
В любом случае вы должны помнить что продукт разрабатываемый без методологии может быть успешнее чем с Scrum/Agile/name it на первом месте.

= Эффективность удаленной работы
Еще долго ни один онлайн инструмент не заменит маркерной доски. Пожалуй колокейшен смогут заменить только нейроинтерфейсы вроде слияния из “Тихоокеанского рубежа”. Я сомневаюсь что удаленная работа может сравняться по эффективности с хорошо организованной офисной работой. Но по совокупности многих факторов удаленный формат работы может быть выгоднее офисной.

Другие доклады секции Команда