«Прерывая программиста ради того, чтобы просто поделиться с ним идеей, потенциально вы пускаете насмарку четыре часа его работы». Разработчик с 17-летним стажем Джордж Диаб объяснил Tech Cocktail суть конфликта бизнесменов и разработчиков, визуализировав его последствия на «Дуге программиста».
Идея против архитектуры
Уважение к собеседнику является неотъемлемой составляющей успеха начинающих стартапов. Рецепт неудач обычно выглядит следующим образом: у человека, желающего начать свой бизнес, появляется идея. Он открывает компанию и становится её управляющим (CEO). Затем начинает поиски человека, способного реализовать эту идею. Наконец, нанимает технического директора (CTO). И тут начинается. Управляющий не понимает, почему CTO всё время говорит «нет». CTO и CEO спорят из-за того, что иногда кажется отсутствием уважения друг к другу. CEO нанимает разработчиков, для того чтобы те внесли корректировки и завершили процесс написания кода. Именно в этом месте необходимо построить мост, который поможет найти больше понимания за счёт улучшения коммуникации.
В целях более наглядной иллюстративности мы рассмотрим столкновение взглядов CEO и СТO, представляющих две стороны противоположные стороны процесса — продажи/ бизнес и программирование/разработка. Идея против архитектуры.
Поделись своим «Почему?»
Одной из главных причин непонимания между CEO и CTO является неспособность понять «почему». Почему основатель компании хочет, чтобы код был написан на этой платформе, а не на другой, если он даже не пишет на этом языке? Почему разработчик не может встроить эту простую функцию быстрее, чем за неделю?
Забавная штука относительно уважения заключается в том, что вы должны продемонстрировать немножко смирения. Сдержать себя и задать вопрос. Показать свое почтение и ответить на вопрос.
Открытость — показатель того, что вы уважаете коллег. «Я нахожусь на стадии обсуждения проекта с потенциальным покупателем, и если мы построим продукт на имеющейся у него платформе, наши шансы на успешное партнёрство возрастут». Наймите человека, которому вы сможете доверить данную информацию. У вас не должно быть подобного рода секретов. «На самом деле, эта простая функция требует перестройки архитектуры по сравнению с изначально оговоренной. Потребуются следующие шаги для реализации изменения».
Вы — в первую очередь это касается программистов — должны научить товарищей по команде отношению к себе, если хотите — заботе о вас. Объясните, что мотивирует вас, делает вашу работу более продуктивной, растолкуйте, когда лучшее время для «похлопать по плечу».
Цените стили работы команды
Людей мотивируют разные вещи. Праздничный обед или путешествие может показаться лучшей наградой для одних и разочарованием для других. Помните, прежде чем раздавать поощрения, следует изучить язык каждого из сотрудников. По той же причине не следует думать, что работа по 8 часов ежедневно в одном пространстве — это путь к наивысшей продуктивности сотрудников.
«Прерывая программиста ради того, чтобы просто поделиться с ним идеей, потенциально вы пускаете насмарку четыре часа его работы. Если же нужно что-то обсудить, будьте точны в определении темы разговора с самого начала», — говорит разработчик Джереми Воуртинк (Jeremy Woertink), который рассказал нам об успехах и неудачах на заре карьеры.
С другой стороны, CEO компании Гейб Шэперд (Gabe Shepherd) признаётся, что ему далеко не всегда приходилось интересоваться технической стороны работы. «Либо будь краток, либо рассказывай всё, — делится Гейб. — Иногда всё, что мне нужно знать, — в чём же загвоздка». По его словам, понимание того, насколько детально нужно изложить конкретный вопрос перед конкретным членом команды, помогло ему улучшить коммуникацию между теми, кому придумывает идее и теми, кто воплощает их в жизнь.
Воуртинк изобразил своеобразную «Дугу программиста»: если вы хотите, чтобы я был в офисе, затыкал все дырки и был доступен для команды, как стол для пинг-понга, моя работа будет менее эффективной и займёт гораздо больше времени. На то, чтобы остальная команда поняла суть этого принципа, ушло какое-то время, говорит программист.
Как отмечает Шеперд, понимание «Дуги программиста» действительно помогло ему улучшить коммуникацию с командой и с теми стартапами, которым он помогал развиваться. «Сначала я подумал, что это всего лишь оправдание, — говорит он. — Если я могу вернуться к работе после того, как меня отвлекли, то почему не может программист?» Когда Шеперд понял, что программисту нужен период для «раскачки», чтобы войти в процесс написания кода, он стал с большим уважением относиться к товарищам по команде.
Понимание «языка», на котором говорит ваша супруга или другой член вашей семьи, важно также, как и понимание потребностей вашей команды. Только так каждый будет чувствовать взаимное уважение, которое и дает в итоге наилучшие результаты.
Про автора. Джордж Диаб (George Diab) — разработчик ПО с 1998 г. Участник #VegasTech и основатель стартапа WorkingOn в Лас-Вегасе. Сотрудничает с GOTO 10 Solutions и OpenFloor.
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.