Данный текст создан на основе моего выступления на GRWebDev. Это история проекта, который был отменен и похоронен в GitHub, а также рассказ об уроках, извлеченных в ходе работы над ним.
В октябре 2012-го года, мы собрали команду, чтобы разработать продукт, который позволил бы компании GitHub, Inc выйти на новые для себя рынки. Этот продукт должен был возникнуть как результат эволюции некоторых внутренних инструментов, которые мы разработали для записи презентаций в нашем головном офисе в Сан-Франциско и их демонстрации нашим удаленным сотрудникам.
Когда наша команда из 6 человек собралась в команде, чтобы дать старт проекту, мы знали 2 вещи:
1) У нас были некоторые внутренние наработки для записи переговоров; и
2) У нас был опыт создания веб-сайта для расшаривания слайдов презентаций (speakerdeck.com)
Наша миссия состояла в том, чтобы объединить эти две вещи в продукт, который позволял бы любой компании или группе пользователей записывать и воспроизводить записи бесед (переговоров) и делиться ими.
Спустя 11 месяцев, наша команда решила прекратить работу над этим проектом.
Участники нашей команды никогда ранее не работали вместе. У нас не было общего опыта, и не было доверия. В типичном для GitHub стиле, у нас не было ни менеджера, ни «дорожной карты». Никто из нас не знал в точности, что, вообще говоря, должен представлять из себя наш продукт?
Лучшие программы выходят у коллективов, где все разделяют единое общее видение, по-настоящему заботятся о результате, и мотивированы, чтобы его достичь. Такого уровня вовлеченности можно добиться только там, где каждый участвует в формировании общего видения и «владеет» его частью.
Постепенно мы завоевали доверие друг друга и наши представления о продукте начали объединяться, но к тому моменту прошло 6 месяцев.
Урок 1: Формируйте единое видение продукта в команде
В месте, таком, как GitHub, где нет ни менеджеров, ни жестких сроков, возникает искушение верить, что «если я просто буду работать изо всех сил на „крутом“ проекте, который меня заводит», то все как по волшебству станет «хорошо и красиво». Это ложь. Успех — это МНОГО работы. Успех приходит, когда намеренно избегаешь критических ошибок и еще и много «везет».
Нет магической формулы, как достичь успеха, и этого я вам не скажу. Но я знаю, что вы не можете сказать, достигли вы его или нет, если вы не знаете как это оценить, по каким критериям. Мы проработали на проекте 6 месяцев, прежде чем впервые сели вместе за стол и обсудили, что можно считать успехом, а что — неудачей на проекте.
Урок 2: Когда вы выработали общее видение, выработайте определение успеха, и, что не менее важно, определение неудачи (провала). Установите цели на пути к «успеху» и регулярно сверяйте состояние проекта с этими целями
Наш проект страдал от серъезной нехватки ограничений. Деньги не были проблемой, во времени мы не были ограничены ничем, и мы сами определяли набор функций продукта. Не каждому в жизни выпадало такое несчастье. Без ограничений, вы не можете определить «важность». Когда «все важно», расставлять приоритеты и принимать решения невозможно.
Хорошо известно, что выбор из слишком большого количества вариантов «парализует» наш мозг. Наши мозги очень хороши, когда надо быстро выбрать из нескольких вариантов. Но когда вариантов становится слишком много, мозг переходит на медленный перебор их всех со сравниванием всевозможных деталей.
То же происходит и в проектах. Разработка ПО для удовлетворения всех требований «сразу» — парализует. ПО создается «по функции за раз». Выберите ограничения, чтобы они помогали вам фокусироваться на «важном именно в данный момент».
Вехи (milestones) — одна из форм таких ограничений (некоторые называют их «дедлайнами», но я предпочитаю «вехи»). Веха — это конкретная дата, к которой вы собираетесь достигнуть некую цель. Фиксированные даты НИКОГДА не должны включать «скоуп» (набор конкретных требований). Если вы будете работать по 60 часов в неделю, чтобы уложиться в вехи, значит вы не поняли того, о чем я говорю. Ограничение не должно заставлять никого работать БОЛЬШЕ. Оно должно помогать вам работать ЛУЧШЕ.
Выберите разумную веху, например «первый бета пользователь через 2 недели, считая от сегодня», или «первая продажа через 3 месяца». Без фиксированного скоупа, дедлайны в сущности становятся целями. Людям, как правило, присуща мотивация на «достижение цели».
Не меняйте установленные сроки, чтобы «допилить» побольше фич. Когда наступает дедлайн, выкладывайте то, что есть. Это может звучать ужасающе, но поверьте мне, как только вы так поступите, вы быстро научитесь фокусироваться на вещах, которые действительно важны, и всегда поддерживать проект в рабочем состоянии.
Урок 3: создавайте искусственные ограничения, которые будут способствовать избеганию неудач и помогут достигнуть успеха
В первые 9 месяцев, я больше заботился об исходе проекта, чем о людях из команды. Я высказывал свои суждения об идеях, дизайне и коде, исходя из предположения, что самое важное в нашем общении — это создание высококлассного продукта. Я ошибался.
Все в команде страдали от выгорания. Постоянные жернова взаимной критики перемололи каждого из нас. Мы утратили мотивацию работать над вещами, которые прежде нас так увлекали, потому что все, чем вы занимались, могло вскоре оказаться «бесполезным» или «сделанным неправильно».
Урок 4: если вы заботитесь о людях, проект позаботиться о себе сам. Не жалейти никаких сил, чтобы обеспечить, что каждому человеку в команде нравится то, чем он занимается. Счастливые люди создают лучшие продукты
Прекращение проекта может быть опустощающим опытом для людей. Многие коллеги подходили ко мне тогда с вопросом «ну ты как сам?» с таким видом, как будто я потерял любимого человека. Потребовалось немало опыта, но постепенно я научился правильно воспринимать «провалы».
Успех — плохой учитель. Поскольку нет формулы успеха, и приходит он столь непостоянно, «предвзятость выжившего» мешает понять, что же именно привело к успеху. Практически невозможно бывает определить, пришла ли команда к успеху «благодаря» или «вопреки» тому, что она делала в проекте.
Остановка (отмена) проекта — это великий и поучительный урок. Принятие решение об отмене становится результатом тщательного взвешенного анализа о том, нельзя ли применить ресурсы, потраченные на проект, с большей пользой где-либо еще. Самым трудным тут является принять это решение в наиболее ранний момент, чтобы не вкладывать ресурсы в нечто заведомо бесполезное.
Урок 5: «Неудача» — это когда вы учитесь тому, как в следующий раз сделать лучше. Мне нравятся неудачи.
Мы получили много полезных уроков за эти 11 месяцев. Перечисленное выше — то, что показалось наиболее важным лично мне. Но ни одна из этих ошибок не стала причиной того, что проект был свернут.
Наш слоган для github.com (сайта) звучит как «Создаем программы лучше, вместе». По мере нашего роста и развития, мы постоянно сталкиваемся с вопросом, является ли это адекватным описанием видения GitHub, Inc (компании). Мы часто говорим, что наше видение компании можно описать как «делать работу вместе более легкой, чем по одному». Учитывая что до 75% наших сотрудников работают удаленно, совместная работа становится особенно нетривиальной когда вы с коллегами в разных временных зонах. Мы сталкиваемся с уникальными, не характерными для большинства компаний, вызовами.
GitHub всегда разделял стремление open source сообщества, в нашем желании создавать программы, помогающие нам решать проблемы, причиняющие нам боль. Мы чувствуем ту боль, которая возникает при совместной (удаленной) работе, поэтому мы всегда готовы «почесать эту корочку». Но думаю, мы гораздо лучше понимаем проблемы, возникающие при совместной работе над программным кодом. Создание инструмента, который облегчал бы совместную работу в других областях, требует очень хорошего понимания различных уникальных проблем.
В конце концов, мы решили свернуть проект, т.к. он не вписывался в видение того, куда движется GitHub. Мне бы хотелось думать, что в других обстоятельствах мы бы учли эти уроки и все же смогли бы выпустить работоспособный продукт. А может, мы бы и не извлекли эти уроки, если бы нас не постигла «неудача».
Так или иначе, я благодарен судьбе за эти уроки и рассчитываю применить эти знания на своем следующем проекте.
В октябре 2012-го года, мы собрали команду, чтобы разработать продукт, который позволил бы компании GitHub, Inc выйти на новые для себя рынки. Этот продукт должен был возникнуть как результат эволюции некоторых внутренних инструментов, которые мы разработали для записи презентаций в нашем головном офисе в Сан-Франциско и их демонстрации нашим удаленным сотрудникам.
Когда наша команда из 6 человек собралась в команде, чтобы дать старт проекту, мы знали 2 вещи:
1) У нас были некоторые внутренние наработки для записи переговоров; и
2) У нас был опыт создания веб-сайта для расшаривания слайдов презентаций (speakerdeck.com)
Наша миссия состояла в том, чтобы объединить эти две вещи в продукт, который позволял бы любой компании или группе пользователей записывать и воспроизводить записи бесед (переговоров) и делиться ими.
Спустя 11 месяцев, наша команда решила прекратить работу над этим проектом.
Вырабатывайте общее видение
Участники нашей команды никогда ранее не работали вместе. У нас не было общего опыта, и не было доверия. В типичном для GitHub стиле, у нас не было ни менеджера, ни «дорожной карты». Никто из нас не знал в точности, что, вообще говоря, должен представлять из себя наш продукт?
Лучшие программы выходят у коллективов, где все разделяют единое общее видение, по-настоящему заботятся о результате, и мотивированы, чтобы его достичь. Такого уровня вовлеченности можно добиться только там, где каждый участвует в формировании общего видения и «владеет» его частью.
Постепенно мы завоевали доверие друг друга и наши представления о продукте начали объединяться, но к тому моменту прошло 6 месяцев.
Урок 1: Формируйте единое видение продукта в команде
Определите «успех» и «поражение»
В месте, таком, как GitHub, где нет ни менеджеров, ни жестких сроков, возникает искушение верить, что «если я просто буду работать изо всех сил на „крутом“ проекте, который меня заводит», то все как по волшебству станет «хорошо и красиво». Это ложь. Успех — это МНОГО работы. Успех приходит, когда намеренно избегаешь критических ошибок и еще и много «везет».
Нет магической формулы, как достичь успеха, и этого я вам не скажу. Но я знаю, что вы не можете сказать, достигли вы его или нет, если вы не знаете как это оценить, по каким критериям. Мы проработали на проекте 6 месяцев, прежде чем впервые сели вместе за стол и обсудили, что можно считать успехом, а что — неудачей на проекте.
Урок 2: Когда вы выработали общее видение, выработайте определение успеха, и, что не менее важно, определение неудачи (провала). Установите цели на пути к «успеху» и регулярно сверяйте состояние проекта с этими целями
Создавайте осмысленные искуственные ограничения
Наш проект страдал от серъезной нехватки ограничений. Деньги не были проблемой, во времени мы не были ограничены ничем, и мы сами определяли набор функций продукта. Не каждому в жизни выпадало такое несчастье. Без ограничений, вы не можете определить «важность». Когда «все важно», расставлять приоритеты и принимать решения невозможно.
Хорошо известно, что выбор из слишком большого количества вариантов «парализует» наш мозг. Наши мозги очень хороши, когда надо быстро выбрать из нескольких вариантов. Но когда вариантов становится слишком много, мозг переходит на медленный перебор их всех со сравниванием всевозможных деталей.
То же происходит и в проектах. Разработка ПО для удовлетворения всех требований «сразу» — парализует. ПО создается «по функции за раз». Выберите ограничения, чтобы они помогали вам фокусироваться на «важном именно в данный момент».
Вехи (milestones) — одна из форм таких ограничений (некоторые называют их «дедлайнами», но я предпочитаю «вехи»). Веха — это конкретная дата, к которой вы собираетесь достигнуть некую цель. Фиксированные даты НИКОГДА не должны включать «скоуп» (набор конкретных требований). Если вы будете работать по 60 часов в неделю, чтобы уложиться в вехи, значит вы не поняли того, о чем я говорю. Ограничение не должно заставлять никого работать БОЛЬШЕ. Оно должно помогать вам работать ЛУЧШЕ.
Выберите разумную веху, например «первый бета пользователь через 2 недели, считая от сегодня», или «первая продажа через 3 месяца». Без фиксированного скоупа, дедлайны в сущности становятся целями. Людям, как правило, присуща мотивация на «достижение цели».
Не меняйте установленные сроки, чтобы «допилить» побольше фич. Когда наступает дедлайн, выкладывайте то, что есть. Это может звучать ужасающе, но поверьте мне, как только вы так поступите, вы быстро научитесь фокусироваться на вещах, которые действительно важны, и всегда поддерживать проект в рабочем состоянии.
Урок 3: создавайте искусственные ограничения, которые будут способствовать избеганию неудач и помогут достигнуть успеха
Люди значат больше, чем продукт
В первые 9 месяцев, я больше заботился об исходе проекта, чем о людях из команды. Я высказывал свои суждения об идеях, дизайне и коде, исходя из предположения, что самое важное в нашем общении — это создание высококлассного продукта. Я ошибался.
Все в команде страдали от выгорания. Постоянные жернова взаимной критики перемололи каждого из нас. Мы утратили мотивацию работать над вещами, которые прежде нас так увлекали, потому что все, чем вы занимались, могло вскоре оказаться «бесполезным» или «сделанным неправильно».
Урок 4: если вы заботитесь о людях, проект позаботиться о себе сам. Не жалейти никаких сил, чтобы обеспечить, что каждому человеку в команде нравится то, чем он занимается. Счастливые люди создают лучшие продукты
«Провал» — не провал
Прекращение проекта может быть опустощающим опытом для людей. Многие коллеги подходили ко мне тогда с вопросом «ну ты как сам?» с таким видом, как будто я потерял любимого человека. Потребовалось немало опыта, но постепенно я научился правильно воспринимать «провалы».
Успех — плохой учитель. Поскольку нет формулы успеха, и приходит он столь непостоянно, «предвзятость выжившего» мешает понять, что же именно привело к успеху. Практически невозможно бывает определить, пришла ли команда к успеху «благодаря» или «вопреки» тому, что она делала в проекте.
Остановка (отмена) проекта — это великий и поучительный урок. Принятие решение об отмене становится результатом тщательного взвешенного анализа о том, нельзя ли применить ресурсы, потраченные на проект, с большей пользой где-либо еще. Самым трудным тут является принять это решение в наиболее ранний момент, чтобы не вкладывать ресурсы в нечто заведомо бесполезное.
Урок 5: «Неудача» — это когда вы учитесь тому, как в следующий раз сделать лучше. Мне нравятся неудачи.
Почему мы отменили проект
Мы получили много полезных уроков за эти 11 месяцев. Перечисленное выше — то, что показалось наиболее важным лично мне. Но ни одна из этих ошибок не стала причиной того, что проект был свернут.
Наш слоган для github.com (сайта) звучит как «Создаем программы лучше, вместе». По мере нашего роста и развития, мы постоянно сталкиваемся с вопросом, является ли это адекватным описанием видения GitHub, Inc (компании). Мы часто говорим, что наше видение компании можно описать как «делать работу вместе более легкой, чем по одному». Учитывая что до 75% наших сотрудников работают удаленно, совместная работа становится особенно нетривиальной когда вы с коллегами в разных временных зонах. Мы сталкиваемся с уникальными, не характерными для большинства компаний, вызовами.
GitHub всегда разделял стремление open source сообщества, в нашем желании создавать программы, помогающие нам решать проблемы, причиняющие нам боль. Мы чувствуем ту боль, которая возникает при совместной (удаленной) работе, поэтому мы всегда готовы «почесать эту корочку». Но думаю, мы гораздо лучше понимаем проблемы, возникающие при совместной работе над программным кодом. Создание инструмента, который облегчал бы совместную работу в других областях, требует очень хорошего понимания различных уникальных проблем.
В конце концов, мы решили свернуть проект, т.к. он не вписывался в видение того, куда движется GitHub. Мне бы хотелось думать, что в других обстоятельствах мы бы учли эти уроки и все же смогли бы выпустить работоспособный продукт. А может, мы бы и не извлекли эти уроки, если бы нас не постигла «неудача».
Так или иначе, я благодарен судьбе за эти уроки и рассчитываю применить эти знания на своем следующем проекте.