В прошлой статье я немного рассказал о потоках в приложении, вернее как я вижу приложение и как вижу в нем проблемы. Сейчас я поделюсь мыслями о том, как здоровье приложения сказывается на работе всей команды.
Да, в работе команды тоже есть потоки.
Можно ошибочно подумать, что некачественное приложение — это проблема исключительно разработчиков. Это не так. Проблемы в приложении будут сказываться на всей команде. И вот почему.
Рассмотрим гипотетическое приложение
В самом начале дела идут неплохо, ведь прогресс на этом этапе виден гораздо лучше. Что-то в сравнении с отсутствием такового — уже гораздо больше. Кодовая база на этом этапе еще невелика, просматривается хорошо, и при хорошей и при плохой архитектуре и даже при ее отсутствии.
Но вот проходит два-три месяца и прилетают первые ласточки. В приложении появляются проблемы. Все чаще разработчики работают над устранением багов. На добавление функционала остается все меньше и меньше времени. Само приложение работает «топорно», деталям внимание не уделяется, потому что это «вторично» (что сомнительно). И примерно через полгода весь процесс сильно стопорится. А за полгода уже можно написать достаточное количество кода, чтобы в нем увязнуть.
Казалось бы, в начале создания приложения работа выполнялась быстрее, но потом что-то пошло не так и началось замедление. Может показаться, что разработчики просто стали меньше работать, но дело скорее всего вовсе не в этом. Все дело в том, что движение потоков в приложении начало запутываться и нарушаться. Ведь если не заботиться об этом и не поддерживать здоровье проекта, то это неизбежно случится.
Что же произошло?
Чем больше кода добавляется в приложение, тем, конечно же, сложнее становится им управлять. Это справедливо и для здоровых проектов и для болеющих, разница лишь в соотношениях. Например: фича/время на реализацию, фича/ количество багов, фича/зона аффекта. У здоровых проектов время на реализацию, количество багов и зона аффекта меньше чем у не здоровых проектов. Я бы даже подчеркнул — сильно меньше. Так же, у здоровых проектов график роста этих параметров гораздо менее стремительный чем у не здоровых. Проблемные проекты в какой-то момент срываются в график — «клюшку» и их практически уже невозможно поддерживать.
В такой момент разработчики могут назвать приложение модным словом — «легаси», тем самым списав с себя всю ответственность. Но легаси не бывает, есть приложения, которые не любили и о которых не заботились. Хорошие приложения всегда служат долго верой и правдой, никогда не помечаются ярлыком легаси, а на заслуженный отдых уходят с почестями.
Здоровье проекта можно посчитать количественно, но сейчас не об этом. Давайте посмотрим, как здоровье приложения сказывается на всей команде.
Наташ, просыпайся, мы все уронили
Итак, приложение уходит из под контроля. Что происходит? Разработчики все больше работают над багами, и уже кажется, что спринт-ревью больше похож на баг-ревью.
Во-первых, сами разработчики начинают эмоционально выгорать. Мало того, что постоянно «прилетают» неполадки, так еще и на «интересные» продуктовые задачи остается меньше времени. Помимо психологического эффекта накладывается и технический — при разработке фичи приходится отвлекаться на фикс багов, продуктивность снижается.
Дальше начинают нервничать тестировщики, т.к. вхождение в шторм вызывает повторные ошибки, зона аффекта растет, приходится постоянно перепроверять все приложение, а это не самая интересная рутина. Да и вообще — ну как так можно, только это поправилось на прошлой неделе и снова появилось после реализации другой задачи.
Продуктовый дизайнер переживает. Он нарисовал красивый макет, вложил в него семантику и смысл. Рассчитал отступы, просчитал типографику, предусмотрел нужную анимацию, но в итоге пока может видеть рандомные спейсы, не опрятные элементы, отсутствие анимации и т.д. Но сейчас же не до этого, можно подождать.
Аналитик старается более подробно описывать задачу, ведь возможно не хватает чего-то для более качественной реализации, собирает встречи по обсуждению чаще. Но это не выравнивает ситуацию.
Владелец продукта с каждым новым демо-днем получает все меньше результатов, начинает поступать информация о том, что нужно усилить разработку, т.к. проект растет, стало быть — нужно увеличить бюджет. Но скорее всего это будет радовать мало.
Руководитель проекта наблюдает за ухудшением ситуации и может постепенно увлечься микроменеджментом. Либо увеличить количество встреч и обсуждений. А от этого, разумеется, никому не станет легче.
Конечно же, проблемы могут возникать не только в коде, но и в других местах. Есть огромное количество нюансов, которые нужно учесть и реализовать, чтобы обеспечить хорошую продуктивную работу. Но на мой взгляд, именно проблемы со здоровьем приложения будут иметь максимальный вес.
Настрой команды
Если посмотреть на весь процесс в рамках команды, то конечно же можно представить общее состояние. При таком настрое больших успехов, конечно же, не достичь. Представьте, если попытка усилить команду увенчалась успехом и начали приходить новые специалисты. Наблюдая за реальным происходящим процессом, желание остаться в команде, где все «перекладывают» друг на друга ответственность или где встреч больше реальной работы, будет небольшим. Кроме того, могут уходить и текущие специалисты. Выходит, что команда заблокирована не только на успешную работу, но и на развитие.
Потоки в команде нарушены. Вот так здоровье приложения, как целевого результата работы команды, может влиять на всю команду.
Если вы руководитель команды, владелец продукта или еще кто-то, в чьих интересах, чтобы приложение работало и развивалось, то наблюдая такие симптомы будьте уверены — приложению плохо, его нужно лечить.
Здесь можно возразить: «Нуу, проблемы могут быть в процессах, в компетентности других специалистов, почему сразу в приложении?»
Отвечаю.
Хорошие разработчики могут вытащить проект даже при слабых остальных позициях. Плохие разработчики могут упустить проект даже при сильных остальных позициях. Убедительно?
Итак, что же делать заинтересованному лицу, в случае накопления вышеуказанных проблем?
Вы — руководитель команды, владелец продукта
Есть такая мудрость — «Если вы поняли, что оказались в яме, то первое, что нужно сделать — это перестать копать». Очень точно сказано.
1. Ни в коем случае не пытайтесь нанять дополнительных специалистов
Мало того, что это совсем не гарантия ускорения и усиление команды, так это еще ее замедление. По крайней мере на ближайшее время. Для расширения команды есть другие маркеры, но сейчас не об этом.
2. Не переходить в обвинение, не повышать давление на команду, не переходить к «ловле блох»
Это так же — точно не поможет. Психологическое здоровье команды это общий фон, он действует на всех сразу.
3. Добавить, если нет, или уделить внимание ретроспективе
На самой встрече не повышать градус негодования, да и вообще не надо негодовать. Нужно обеспечить комфортную рабочую атмосферу и действительно обозначить проблемы, обсудить возможные пути решения.
4. Предложить помощь тому, кому это требуется
Речь идет о том, чтобы привлечь внешний ресурс для консультации и помощи тому специалисту, кому это нужно. Это в целом никогда никому не повредит. Т.к. я почти уверен, что проблема в здоровье приложения, то нужно поискать проверенного разработчика, который мог бы посмотреть на код и дать рекомендации. Возможно помочь какое-то время с написанием кода. На самом деле, это может быть не обязательно разработчик в том же стеке. Навык написания хорошего кода — кроссплатформенный.
5. «Не стреляйте в пианиста»
Каждый человек всегда делает то, что может. И на самом деле, разработчик может даже не понимать, что есть проблема в коде, если он никогда не работал с хорошим кодом. А если он никогда не работал с хорошим кодом, то будет убежден в том, что времени на разработку слишком мало или ошибки в коде — это нормально. Конечно, наличие ошибок в любой деятельности — это нормально, это точки роста. Другой вопрос, если их количество затрудняет работу и блокирует развитие приложения.
В этом случае помощь извне будет весьма кстати. Поговорите в разработчиком и предложите консультанта. Рост и общение с другими специалистами — это всегда хорошо. Не обязательно принимать в штат этого консультанта, можно договориться о трекинге. А разработчик, который начнет видеть, как код преобразовываться, скорее будет только рад. Это инвестиция в команду.
Вы — разработчик
Что делать, если возникли сложности, да или даже если не возникли.
1. Трезво оцените ситуацию
Если вам стало тяжело добавлять функциональность. Если работа над багами отнимает много времени. Если на фиксацию среднего бага уходит более 30 минут. Если вы скипуете «украшательства» дизайнера, оставляя их на потом как не нужные. Если вы начинаете ощущать, что времени на добавление функционала необходимо все больше. То нужна внешняя помощь. Рассматривайте это не как оскорбление или слабость, но как точку роста.
2. Не пытайтесь взять время на «Рефакторинг»
Скорее всего — это не поможет. Потому что настоящий рефакторинг — это постоянная работа. Вы не должны начинать добавлять код, если не подготовите его к работе. Но об этом в других статьях.
3. Попросите помощь или консультацию
Придите к руководителю и попросите помощи. Не «еще одного» дополнительного разработчика, а помощи, консультации. Это нормально и хорошо. Можно поискать самому (и даже лучше самому) специалиста, с которым хотели бы пообщаться и предложить его кандидатуру.
Возможно есть кто-то в поле вашего зрения, с кем вы хотели бы пообщаться — это отличный шанс повысить свой скилл. Например, очень хорошая практика пообщаться с кем-то по определенной области, например по созданию своей дизайн-системы, или по работе с базой данных или с авторизацией и т.д. Поверьте, пара консультаций вам может сэкономить месяцы в обучении.
4. Никогда не останавливайтесь обучаться
Скорее всего вы и так смотрите видео, читаете статьи и книги, ходите на конференции. Это отлично. Интересуйтесь так же новыми языками, но все же придерживайтесь своего основного языка. Скорее всего там еще есть что изучить. Продолжайте в том же духе. Искусство программирования — это практически бесконечный фрактал.
Вы — любой другой член команды или просто знакомый знакомого члена команды
1. Поделитесь найденным
Поддержите канал, отправив эту статью тому, кому посчитаете будет полезно. И прочитайте сами. А еще лучше — подпишитесь :) Возможно будут интересны и будущие статьи.
Как поддерживать результат
Как я уже написал, отладка процесса разработки — тема обширная и достойна отдельной статьи. Но немного затрону и эту тему.
На мой взгляд, для поддержания состояния потока в команде должно выполняться одно простое правило — нужно делать хорошо и чуточку лучше. Вот это «чуточку» имеет огромное положительное влияние на всю команду и вызовет синергетический эффект. Видя как ваши результаты блестят в глазах других членов команды, вы будете наполняться положительной энергией еще больше. И так будет у каждого.
Работа в таком поле будет максимально продуктивной и результат не заставит себя долго ждать.
Вдохновляйте друг друга.
Остальные же процессы и ритуалы в команде — это вторичные явления и должны внедряться по необходимости.
Итог
Может показаться, что я сгущаю краски и накладываю излишнюю ответственность на разработчиков. Возможно :) т.к. я сам разработчик и у меня есть профессиональная деформация.
Однако, я навсегда запомнил одну фразу, которую услышал весьма давно на одном из технических мероприятий, кажется когда проходил интенсив от ФРИИ.
«Разработчик — это единственный специалист, который может построить проект полностью, от начала и до конца».
И это действительно так. И именно это я подразумевал говоря о том, что сильные разработчики легко вытащат проект, даже при наличии пробелов в компетенциях команды.
Скорее всего, большинство подписчиков — разработчики, поэтому обращаюсь к вам, ребята:
Любите свой код и заботьтесь о нем, развивайтесь сами и развивайте свой код. Будьте в первую очередь инженерами, находите лаконичные решения для сложных задач. Ответственно подходите к поставленным задачам и делайте «чуточку» больше.
Удачи в вашей работе!