«Разговоры со знаменитостями» — СПЕЦПРОЕКТ COSSA И AGIMA
Фред Джордж о проектировании и разработке
40 лет IT-консалтинга, 70 языков программирования, 12 лет работы по Agile.
Cossa и AGIMA продолжают спецпроект Разговоры со знаменитостями. В этот раз мы поговорили об управлении процессами разработки с Фредом Джорджем.

Фред Джордж
IT-консультант с более чем 44-летним опытом работы в области разработки. Более двадцати лет занимается объектным программированием и более дюжины лет — Agile. Писал код не менее чем на 70 языках. Среди его клиентов — HP, Morgan-Stanley, American Express, IBM и USAA.

Профиль на LinkedIn
— Чем, по вашему мнению, должен заниматься настоящий тимлид? Это больше senior-разработчик, который делает самые сложные задачи, или скорее менеджер, который управляет своей командой? Может ли хороший тимлид быть плохим разработчиком?
— Не стоит смешивать техническую компетентность и лидерство. Понятно, что самый технически продвинутый специалист пользуется уважением в команде, и здесь есть предпосылки для лидерства. Тем не менее, хорошие руководители с уважением прислушиваются ко всем участникам команды. Они следят, чтобы нужные решения принимались вовремя. При этом тимлид не должен решать всё сам — это может демотивировать остальных. Без специальной подготовки даже самому крутому техническому лидеру сложно осознать важность коллективных решений — и поставить их выше собственного мнения.
«Менеджер» — еще одна ущербная модель. Технические решения должны приниматься технарями. Кроме того, менеджер — это такая точка контакта, на которую удобно давить всем — и заказчикам, и высшему менеджменту. От этого риск неверных решений становится ещё выше.
Я предпочитаю модель ситуационного лидерства, когда лидеры меняются по мере выполнения проекта. С их выбором лучше всего справляется сама команда («Кто из нас справится с этим лучше?»). В начале проекта, когда ключевое значение имеет архитектура и выбор технического направления, эта роль может достаться сильному технарю. Позже, когда проект приближается к завершению и сдаче, она может перейти к тому, кто дотошен в деталях и отладке. Мне очень редко встречались тимлиды, которые идеально работали на всех этапах проекта.
— Какими компетенциями должен обладать настоящий тимлид?
— Три важнейших качества отличного тимлида:
Эмпатия
Способность чувствовать настроения команды
Решительность
Готовность принимать решения, когда информации недостаточно
Профессионализм
Техническая компетентность
Эмпатия, или EQ (эмоциональный интеллект) позволяет руководителю чувствовать настроение людей, понимать особенности отношений внутри команды. Распознать конфликт, когда он еще только назревает — и не дать команде рассыпаться. За это отвечает эмоциональный интеллект. Проблемы в команде и проекте часто связаны не с техническими сложностями, а с человеческими.

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

В технической сфере нельзя выбрать верный путь, не обладая технической компетентностью (я не имею в виду её выдающийся уровень). Взвесить все «за» и «против» невозможно, если вы не разбираетесь в технологиях.
— В каких проектах/компаниях, по вашему мнению, должна быть отдельная роль «архитектор», а когда в ней нет смысла?
— Я уже, по меньшей мере, лет двадцать не вижу смысла в архитекторе как отдельной позиции. Полагаю, что в классических масштабных и многолетних проектах она существует. Однако в моей сфере технологии развиваются слишком быстро, и это сильно влияет на разработку. Архитектор, не включенный в неё непосредственно, очень быстро утратит свои навыки и будет создавать устаревшую и неудачную архитектуру.

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

Если же в заголовке резюме я вижу именно слово «архитектор», то обычно сразу отказываю. От такого специалиста будет больше вреда, чем пользы.
— Во все времена у успешных компаний во главу ставились бизнес-цели, а не идеальный код. В этой логике допустимо, что мы сделаем не самое красивое (с точки зрения кода) решение, но зато быстро решим бизнес-проблему. Как определить грань между допустимой деградацией качества кода и полным хаосом?
— Лучшее — враг хорошего. Я сознательно следую этому принципу в самых важных проектах.

*Кент Бэк
Создатель методологий экстремального (XP) и тестировочного программирования (TDD).
Если бизнес-цели, при всей их сложности, ясны, то я за идеальный код. Если же решение не удается нащупать сразу, то добиться результата можно, перепробовав как можно больше вариантов. Кент Бэк* называет это eXplore-фазой. В этой ситуации надо склоняться скорее к хорошему, чем к идеальному. Если код в это время производит впечатление чего-то хаотичного, то это отражает недостаточное понимание проблемы на уровне самого бизнеса. Как только бизнес-решение станет яснее — почистите код.
— Как управлять «техническим долгом», накапливающимся в результате компромиссных решений?
— Я против термина «технический долг». Это эвфемизм для слов «лень» или «невежество». Лень в том, что программист выбрал самый короткий и легкий путь — в ущерб профессионализму. Невежество — потому что у него не хватило знаний и умений, чтобы сделать эту работу правильно. По моему опыту, так называемый технический долг был предопределён управленческим решением менее чем в 10% случаев. Фраза «менеджер велел мне на этом остановиться» — скорее оправдание ленивого программиста.
— Работа по бизнес-целям может стать «токсичной средой» для разработчиков, вызывать у них ощущение, что менеджменту нет дела до качества продукта, что им важнее сиюминутный результат. Как избежать формирования такого восприятия?
— Много лет назад я пытался убеждать руководство, что мне нужно ещё немного времени, — тогда я напишу более качественную программу. Каждый раз мне говорили, что лучше сделать побыстрее. Я больше не задаю таких вопросов. Ответ всегда один и тот же: надо быстрее.

К счастью, я открыл для себя Smalltalk и объектно-ориентированный подход. Оказалось, что Agile-методы (и быстрая разработка приложений в целом) базируются на особом стиле программирования, который позволяет легко вносить изменения в программу. Если же не следовать этому стилю, то вы создадите систему, изменять которую будет всё сложнее и сложнее. К сожалению, этому подходу не учат в университетах, и он не очень широко распространён в отрасли. Обучение ему — первое, с чего я начинаю работу со своими клиентами, и уже после этого мы приступаем к разработке. Между прочим, это не замедляет работу над проектом, а в дальнейшем даже ускоряет её. Этот стиль не требует компромисса между «хорошо» и «быстро».
— Как вообще правильно поступить в ситуации, когда бизнес-цели требуют быстрого решения, а разработчик настаивает, что такое решение противоречит внутренней логике продукта и в будущем приведёт к большим проблемам. И с его точки зрения правильно было бы выделить ещё месяц времени и сделать «как надо»?
— В этом случае избежать конфликта тоже помогает правильный выбор стиля программирования. Конечно, с базами унаследованного кода бывают проблемы. Тогда я стараюсь изолировать нестандартный фрагмент от остального кода. Теперь этот код можно переписать. Иногда для изоляции нужны специальные SQL Views (вместо доступа к данным напрямую), пре- и постпроцессинговые процедуры и т. д.
— Должен ли рефакторинг быть постоянным процессом, вплетенным в плановое производство, или же рефакторинг стоит запускать, когда на развитие проекта необходимо тратить больше времени, чем на разработку?

*Мартин Фаулер
Автор книг и статей по архитектуре ПО.
— Если мы находимся на eXplore-фазе, как её называет Кент Бек, то рефакторинг стоит на втором месте, первоочередная задача — попробовать как можно больше решений. Но когда эта фаза уже миновала, нужно объяснить руководству, что нужен рефакторинг. И тут я придерживаюсь подхода Мартина Фаулера (Martin Fowler)*: «Не говори им об этом».

С моей точки зрения, код еще просто не готов. Кроме случаев, когда: 1) код работает, 2) код взаимодействует, 3) удалены дубликаты кода, 4) все экстра-классы, методы и API были удалены. Тогда работу можно закончить.

Чтобы обучить этим навыкам, я настойчиво использую парное программирование. Эти умения и скрупулёзный подход к процессу — часть особого стиля программирования в Agile-разработке.
— Нужны ли разработчику социальные навыки? Или его нужно максимально отгораживать от конечного заказчика и держать менеджера-«переводчика», который будет передавать и разъяснять запросы от клиента?
— Я предпочитаю говорить о роли амбассадора, «посланника» команды. Это разработчики, которые взаимодействуют с внешними партнерами — будь то заказчики, пользователи или другие команды разработчиков. Амбассадору нужны навыки коммуникации. Как и посол страны, он должен понимать потребности другой стороны. В то же время, как и у настоящего посла, у него нет полномочий решать что-либо единолично. Его позиция не позволяет втянуть команду во что-то — без её ведома, не обсудив решение с другими участниками.

Правильно, когда в качестве амбассадора, отвечающего за внешние взаимодействия, выступает кто-то из разработчиков, а не специальный менеджер.
— Обратная связь от пользователей очень полезна при исправлении ошибок. Но стоит ли слушать пользователей в вопросах стратегии развития продукта?
— Обратная связь от пользователей важна, но стоит помнить об эффекте WYKIWYL (What You Know Is What You Like): «Что знаешь, то и нравится». Если у вас радикальная идея, в корне меняющая сам подход, то вряд ли стоит ориентироваться на мнения пользователей прежних программ. А вот для улучшения существующих систем такая обратная связь очень ценна.

Когда я разрабатываю систему на замену существующей, я прихожу к её пользователям в офис. Я смотрю на разные «артефакты» — стикеры, шпаргалки и т.д., и понимаю, чего не хватает, какие функции должны быть уже в самой программе.
*GUI — графический интерфейс пользователя.
С другой стороны, я сам причастен к радикальным изменениям, например, к разработке GUI-интерфейсов, когда сами пользователи были скорее за изменение существующих технологий, чем за создание чего-то нового. Другой пример — iPhone, представленный Apple.
— TDD — это хорошо или плохо? :-)
*TDD, test-driven development — разработка через тестирование
— TDD даёт быструю обратную связь — работает или нет то, что вы только что сделали. Быстрый фидбек необходим для быстрой и качественной разработки. Но TDD не единственный способ получить такую обратную связь. Что, если испытать ваш продукт на настоящих пользователях в реальном времени? В Лондоне я работал в компании, где не было никаких промежуточных звеньев: вот ноутбук — и вот сам продукт; никакого временного сервера, никакого сервера тестирования. Мы зарабатывали 50 миллионов фунтов стерлингов командой из 50 человек.

Однако, если нельзя получить быструю обратную связь по продукту от пользователей, я всегда пользуюсь TDD. Я очень настойчиво обучаю TDD — это часть моей стартовой программы подготовки программистов, потому что постоянное развёртывание программного обеспечения до сих пор ещё редкость.
Комментирует Андрей Рыжкин,
руководитель отдела
разработки AGIMA

У нас в AGIMA, наверное, самый большой опыт построения института тимлидеров среди всех агентств и интеграторов и реально лучший продакшн в России.
Тимлид, как роль, представляет огромную ценность для бизнеса. Это тот человек, который принимает взвешенные решения, снимает риски, повышает эффективность команды. Он один может спасти проект, в конце концов! И я говорю не о том, что он сам в режиме 24×7 будет дорабатывать проект после горе-разработчиков.
Интересно, что многие разработчики вообще не представляют, кто такой тимлид и романтизируют эту должность. Некоторые из тех, кто приходил к нам на собеседование на эту позицию, считали, что всегда будут забирать себе самые интересные задачи, копаться в технологичных вещах, а не заниматься мелочью. Некоторые кандидаты думали, что тимлид обязательно должен быть максимально прокачанным в технологиях, а кто-то наоборот, говорил, что ни за что не пойдет на эту должность, так как не хочет становится менеджером.

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

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


comments powered by HyperComments
Понравилось? Поделись с друзьями!
Другие беседы спецпроекта
Made on
Tilda