Я уже больше года занимаю должность технического руководителя в своей компании и хотел бы поделиться своими наработками по этой теме.
Имеет смысл уточнить: я руковожу отделом iOS-разработки из 10 человек в аутсорсинговой компании.
В моем случае должность предполагает оптимизацию работы отдела, распределение задач между разработчиками и деятельность, связанную с программированием.
Расскажу немного о своем опыте, разработках и выводах.
Статья может быть полезна в первую очередь новичкам в подобной должности или тем, кто к ней стремится.
Некоторые практики и принципы можно перенести в регулярную разработку, на другие платформы или даже на другие специальности.
Обязанности
Чтобы понять, что именно мне предстоит делать, имеет смысл начать со списка обязанностей.К ним относятся:
- Обязанности разработчика:
- Написание кода, рефакторинг
- Обзор кода
- Консультации специалистов других отделов по техническим вопросам
- Оценка трудоемкости проектов и отдельных задач
- Участие в подборе персонала
- Оптимизация работы отдела:
- Повышение технических навыков разработчиков
- Определение порядка выполнения стандартных действий
- Разработка готовых решений
- Введение новых сотрудников в отдел
- Использование времени простоя разработчика
- Распределение задач:
- Задачи по проектам, требующим временного вмешательства
- Задачи внутри отдела
- Смета проекта на продажу
- Консультирование менеджмента по вопросам распределения разработчиков между проектами
Большинство разработчиков выполняют стандартный набор действий и хорошо в них разбираются, поэтому мне хотелось бы сосредоточиться на управлении отделом.
Оптимизация работы отдела
В чем же оно могло заключаться на самом деле? Очевидно, в повышении скорости и качества выполнения стандартных задач.Казалось бы, обычно случается либо одно, либо другое, но здесь важно набраться опыта – компания реализует большое количество проектов, в процессе работы решаются одни и те же проблемы, и со временем можно выявить наиболее удачные и логичные решения и научить кафедру ими пользоваться.
Это глобальная идея оптимизации.
Давайте пройдемся по средствам, которые позволяют это в определенной степени реализовать.
Документация
Стандартные действия могут и должны быть документированы.Письменная информация лучше запоминаемой по многим причинам:
- Он предоставляется всем в одинаковом виде.
- Ее презентация всегда будет полной и корректной, без «испорченного телефона».
- Его изучение только тратит время студента.
- Оно не теряется ни из-за плохой памяти, ни из-за недоступности определенных людей.
- Вы всегда можете обновить его
- Он не рассинхронизируется при изменении
- В процессе фиксации и доработки детально продумываются все важные аспекты.
- Действия внутри инструкций могут подлежать автоматизации.
- .
мы можем продолжить
Это могут быть рекомендации по коду, процедуры прохождения оценок или проведения собеседований, правила работы с репозиториями или баг-трекер — все, что нужно делать постоянно и чему приходится учить новых людей снова и снова.
Самая сложная задача — научить людей пользоваться документацией.
Прежде всего, нужно донести до всех, что информация доступна.
К нему нужно обращаться, а не пересказывать самому.
Крайне важно поддерживать документацию в актуальном состоянии, иначе работа над ней будет просто пустой тратой времени.
Никакой пользы это не принесет, так как не будет доверия к неактуальным источникам информации, они снова не будут использоваться, а время будет потрачено впустую.
В идеальном мире в разработке общей документации должен участвовать весь отдел — тогда все будут понимать, какая документация имеется, где ее искать, как ею делиться, да и сама информация будет актуальной.
Я не призываю создавать бюрократию и прикрывать каждое мелкое движение инструкциями, это неэффективно.
Но имеет смысл определить самые основные вещи, записать их и начать доносить до людей.
Портативный код
В случае с мобильной аутсорс-разработкой у нас есть относительно небольшие по размеру и сроку жизни проекты, в которых большая часть функционала аналогична или даже повторяется.В этом случае вы можете создать базу кода, переносимую между проектами.
Это могут быть стандартные утилитарные функции, какие-то элементы управления, отдельные слои или что-то еще.
Если у отдела есть своя история, в любом случае уже есть какие-то разработки, которые передаются между проектами просто отдельными файлами.
Этот вариант проще, но код модифицируется под нужды одного проекта, и при повторном использовании его модификации могут отличаться.
Выделение переносимого функционала в отдельные репозитории позволяет более продуктивно разрабатывать и стабилизировать решения.
Использование менеджеров зависимостей еще больше сокращает время повторного использования, хотя увеличивает время обслуживания и вводит свои собственные ограничения.
Если изначально нет кодовой базы, разработчикам может быть непривычно и неудобно распихивать решения в отдельные репозитории, потому что «зачем мне заморачиваться, если это уже работает»? Возможно, кому-то придется объяснить, что стратегически, с точки зрения работы компании, так будет лучше.
Со временем процесс входит в привычку, не создает проблем и не вызывает непонимания, поскольку воспринимается как нечто само собой разумеющееся.
Автоматизация
Некоторые стандартные действия можно автоматизировать.Это упрощает рутинные действия, ускоряет работу, снижает человеческий фактор и иногда привносит возможности, которые практически невозможно реализовать вручную.
Стандартный пример: автоматизация процесса сборки позволяет значительно (иногда практически до нуля) снизить затраты на подготовку сборки и в обязательном порядке внедрить в процесс статический анализ или тестирование (я имею в виду, что можно запретить сборку без успешного статического анализа) .
Другой пример: вспоминая специфику отдела, можно сказать, что процедура запуска проекта поддается автоматизации.
Наш отдел использует шаблон, который может генерировать исходное содержимое репозитория со структурой проекта, настроенной по всем рекомендациям, а также настроенными git и непрерывной интеграцией.
Его использование значительно упрощает и ускоряет старт новых проектов.
В общем, простейшим случаем автоматизации можно считать создание различных шаблонов документов, кода или чего-либо еще.
Единообразие
При разработке часто теряется время на погружение в проекты, так как они могут быть по-разному структурированы, и одни и те же задачи могут решаться по-новому снова и снова без видимых причин.Начиная новый проект, где опять же все делается по-своему, разработчик потратит некоторое время на изучение инструментов.
Если у него за плечами не один десяток проектов, разницы не будет — он уже будет примерно представлять, как можно решать стандартные задачи.
Если у вас нет большого опыта, время будет потрачено зря.
Здесь вы сможете сэкономить, приведя разработку к единому виду.
Для достижения единообразия проектов применимо все, что уже было перечислено: общие правила, база решений типовых задач, автоматизация.
Используя их, вы сможете сделать проекты чем-то похожими и понятными для новых разработчиков.
Не стоит слишком усердствовать — проекты не обязательно должны быть похожи, как две капли воды.
Экспериментировать с инструментами и архитектурой важно как для получения удовольствия от получения опыта, так и для изучения потенциальных инноваций.
Имеет смысл систематически экспериментировать, начиная с одной базы.
Ээффективность решений
В идеальной картине мира нужно следить, оправдает ли себя то или иное решение.Пройдя определенный порог, затраты на его поддержку могут превысить выгоды.
Лучший и единственный объективный показатель здесь – время.
Если есть возможность хотя бы изредка смотреть затраты на поддержку всего используемого комплекта, например, по месяцам, это может помочь лучше сориентироваться.
К сожалению, времени у меня мало, и приходится все определять на глаз.
Кроме того, некоторые потенциально неэффективные решения иногда становятся возможными для поддержки благодаря внезапно освободившимся разработчикам.
Реальное развитие в этом отношении может отличаться от логического теоретического.
Увеличение количества используемых инструментов и объема документации может затруднить поддержание всех разработок или даже их использование.
Например, гораздо легче забыть об одном правиле из 50, чем об одном из 5. Найти баланс между функциональностью и сложностью с этой точки зрения — не самая тривиальная задача.
Не могу сказать, что мне удалось найти этот баланс и добиться того, чтобы наработки были использованы на полную катушку.
Образование
Я потратил много времени на создание системы обучения разработчиков.Построив качественную систему обучения, вы сможете решить сразу несколько задач:
- Повышение технических навыков разработчиков
- Предоставление информации о наличии инструкций и готовых решений
- Обеспечение доступа к типичным видам деятельности
- Направление роста разработчиков в правильном направлении
- Эффективное использование времени простоя
- Более десятка шагов, от самых азов до хардкора
- Общий объем информации примерно за пару лет обучения
- Уровни включают тестовые задания, инструкции и теоретическую часть.
- Приемка этапа осуществляется в два этапа:
- Выполнение тестовых задач с ревью кода
- Собеседование по инструктажу и теоретической части
- Прием шагов осуществляется практически непрерывно, минимальный интервал между собеседованиями – одна неделя.
- Разрешения на деятельность привязаны к системе
использовал.
Шаги включают инструкции по выполнению определенных действий (написание кода, запуск проекта, оценка), и по мере выполнения шагов разработчики получают соответствующие разрешения.
Обучение начинается с вводного этапа, который содержит рекомендации по коду, инструкции по работе с системой контроля версий и баг-трекером, а также самые основы программирования.
Придя в компанию, разработчики допускаются к работе над проектами, уже отчитавшись о своих знаниях о том, как мы работаем и минимальном наборе навыков, а также выполнив тестовый проект и пройдя в процессе соответствующую проверку, то есть полное понимание рабочего процесса.
Обучение разработчиков — длительный процесс даже в рамках единой системы, поэтому на проработку материала и формы его принятия уходит много времени.
Дело осложняется тем, что изучение информации длится неделями и месяцами, поэтому быстро сформулировать и апробировать разделение материала на этапы невозможно.
Прием шагов также происходит относительно редко, что требует максимального внимания – сначала необходимо использовать каждую процедуру сдачи для получения информации об удобстве системы.
Распределение задач
Структура нашей компании реализована таким образом, что технический руководитель не занимается распределением разработчиков.Участие в формировании команд имеет консультативную форму: кто с кем лучше объединится, справится ли та или иная команда с проектом и т.д. В мои обязанности входит только обеспечение выполнения задач, не являющихся активными проектами.
Если есть относительно свободные люди, им можно дать оценку трудоемкости заявок на продажу или, например, срочных задач на формально приостановленных проектах, где их совершенно некому выполнять, или внутриведомственной деятельности или чего-то еще.
Если свободных ресурсов нет, нужно все делать самому.
Передача задач одновременно проста и сложна — нужно проверить, кто свободен в данный момент, лично обратившись к разработчикам и менеджерам проектов.
Я пока не смог придумать ничего более эффективного, чем обычный диалог, хотя инстинкт подсказывает мне, что должна быть какая-то возможность сделать это проще и прозрачнее.
Единственное, что мы смогли придумать для упрощения общения, — это общий чат для разработчиков.
Иногда, написав туда, можно узнать, что вдруг кто-то освободился и может выполнить необходимую работу.
Процесс делегирования задач и контроля исполнения — не самая простая область, и мне удалось освоить только самые его основы, поэтому никаких откровений здесь не будет. Все задачи имеют степень передаваемости — насколько эффективным и безопасным может быть их делегирование.
Всегда можно поручить какое-нибудь простое задание, выполнить которое будет сложно так, что оно серьезно что-то испортит. Всегда лучше быть готовым к худшему развитию событий, хотя все зависит от уровня исполнителя.
Если уровень разработчика высок и есть доверие, можно делегировать большие и сложные задачи или даже сформировать общее видение по тому или иному вопросу.
Требования к выполнению переданного задания всегда должны быть указаны максимально точно, чтобы исключить элементарные ошибки и уменьшить возможность неправильной интерпретации.
Также нельзя забывать о проверке результатов.
Понятно, что по мере роста отдела необходимо разрабатывать структуру, в которой обязанности будут дополнительно распределяться на постоянной основе, либо разбивать целый отдел на несколько более мелких, но на моей практике до этого не дошло.
Как справиться со всем этим
Если посмотреть на вышеизложенное и представить, сколько времени необходимо на каждое из этих действий, то станет ясно, что позиция предполагает действительно много задания.Это не будни разработчика, когда в обычный день у тебя одно-два, максимум пять однотипных занятий.
Мой типичный день включает 5-10, иногда 15 задач, причем тип задач может сильно различаться.
Мозг работает совершенно по-другому, когда вам нужно исправить сложную ошибку, изучить новую технологию или создать, спланировать и расставить приоритеты задач.
Поскольку большую часть времени я не привязан к одному проекту, а работаю сразу над несколькими, мне нужно каждый день быстро загружать и выгружать в голову большие объемы разного типа информации.
Поскольку от природы мой мозг не обладает выдающимися параметрами и не может самостоятельно вынести такую нагрузку, я должен ему помочь.
Я уверен, что все эти практики уже придуманы в умных книгах по тайм-менеджменту, но я не уделил достаточно времени их изучению, так как моим приоритетом было и остаётся развитие в сторону программирования.
В моем случае хуже всего справляется память, поэтому часть практики направлена на замену памяти мозга сторонними средствами и привычками.
Вторая группа предполагает привлечение к исполнительской деятельности других людей.
Начнем с последнего и потихоньку перейдем к первому.
Делегация .
Я уже немного говорил о нем.
Если у вас мало времени, постарайтесь максимально делегировать эту работу другим.
Привлечение разработчиков на культурном уровне .
Если в отделе выработаются хорошие привычки, некоторые действия можно будет выполнять даже без ведома технического руководителя.
Например, ошибки в переносимом коде могут исправлять разработчики в рамках обычного выполнения задач по проектам.
Контрольные списки .
Чтобы не забывать о порядке действий, можно составлять их списки: на обычный рабочий день, на выполнение определенного действия, на отдельную задачу или на случай определенного события (например, обновления инструмента).
.
Со временем необходимость в чек-листах отпадает, так как соблюдение их входит в привычку, но поначалу они могут быть очень полезны.
Напоминания .
Когда я выполняю задачу, я стараюсь оставлять себе напоминания о каждой мелочи на случай, если отвлекусь или что-то забуду во время работы.
Это может быть «TODO» в коде, заметка в отдельном документе или на листе бумаги.
Вам необходимо максимально застраховаться от того, что в ходе работы что-то будет забыто и не выполнено.
Дисциплина .
Вам нужно выполнять задания полностью, чтобы больше не нужно было их запоминать.
Статусы в системе управления проектами необходимо устанавливать своевременно; время следует списывать сразу по завершении работы над задачей, ведь после выполнения десятка разных задач и исчерпания ресурсов мозга легко забыть, что вы делали сегодня.
А если задач было много и они были маленькие, о них легко вообще забыть, и тогда получается, что рабочее время как будто ушло впустую.
Если задачи выполняются сразу в полном объеме, в вашем пуле параллельных действий их будет гораздо меньше, чем было бы, если бы вам приходилось неоднократно возвращаться к уже выполненным.
Отказ от коммуникаций .
Много обязанностей означает много коммуникаций.
Отвечать на письма и сообщения в мессенджерах можно после завершения текущей деятельности.
Самое мощное общение — личное, и труднее всего стоять в очереди.
Когда люди подходят ко мне, пока я делаю какое-то задание, мне часто приходится говорить им, что я занят и не могу говорить.
В противном случае контекст мыслей будет постоянно теряться, и после разговора вам придется все вспоминать заново.
При определенном объеме коммуникаций, если в них не отказываться, производительность при выполнении сложных и объемных задач упадет, иногда почти до нуля.
Перевернуть человека, обратившегося лично к вам, бывает сложно, но когда задач большое, это необходимо.
Список заданий
На мой взгляд, важнейший инструмент, достойный отдельного пункта.Если вы не можете держать все свои задачи в голове, вам нужно их отслеживать.
Здесь нужно что-то более бесплатное, чем трекер ошибок.
Я использую простой текстовый документ. Когда приходит новая задача, она просто добавляется в список, чтобы порядок примерно сохранялся в зависимости от приоритетов.
Когда активная задача заканчивается, я возвращаюсь к списку, выбираю пункт с наивысшим приоритетом и берусь за него.
Таким образом, время не тратится на поиск задач.
При необходимости вы можете оценить, сколько времени потребуется на каждое действие из списка, и установить сроки их выполнения.
Такие оценки, однако, не всегда верны, поскольку задания поступают в случайном порядке, и заранее неизвестно, когда и сколько их появится еще.
Однако с этим тоже можно бороться, выделяя определенное время в день для внезапной занятости и давая пессимистические оценки.
Я вынес в отдельный раздел списка пункты, связанные с проверкой выполнения переданных мероприятий.
Если задачу выполняет другой человек, необходимо периодически проверять статус, иначе она может просто потеряться, так как мало кто из разработчиков заботится о том, чтобы ничего не забыть.
Для некоторых ведение простого списка задач может показаться ездой на велосипеде, но это простая и практичная практика, которая поможет вам сэкономить время и не забывать о задачах.
По крайней мере, радикально сократить количество забытых.
Чувствовать
Кажется, он описал, что я делаю и как со всем этим справляюсь.Можно добавить немного текста о собственных ощущениях от работы.
Возможно, это поможет кому-то решить, стоит ли это делать.
Результат не ощутим .
Если я занимаюсь проектами, то это скорее стартап, и в конечном итоге им занимаются другие люди.
Обучение разработчиков невозможно отслеживать напрямую.
Чтобы понять, работает ли то или иное решение, нужно выполнить одни и те же задачи с ним и без него, собрать статистику затрат на его разработку и поддержку и сделать выводы.
В наших условиях времени на такую проверку нет и быть не может. В результате невозможно отследить, насколько правильные или неправильные мои действия.
Соответственно, представить результаты моей работы в чистом виде также невозможно.
Морали это не добавляет. Проекты стали обезличенными .
Когда разработчик делает хотя бы один полноценный релиз приложения, он начинает хорошо понимать его поведение.
Когда речь идет только о запуске приложения, проверке или исправлении нескольких сложных ошибок, вспомнить о проектах невозможно.
Даже технологии, кажется, везде одинаковы.
Простые задачи достаются разработчикам .
Крайне редко кто берется за простые вещи.
Мне очень нравится заниматься простой версткой стандартных экранов и настраивать пиксели и цвета, бороться с проблемами UIKit, но в последнее время большая часть задач связана с построением архитектуры приложений.
Кратковременная память ухудшилась .
Переваривание больших объемов информации изначально перегружало мозг.
Я стал его разгружать, и это привело к тому, что он практически отвык запоминать то, что не было записано.
Возможно, это справедливо только в моем случае.
Изменить рабочий контекст стало проще .
Как оказалось, этот момент можно тренировать.
Мозг привык к постоянному переключению между задачами и справляется с ними гораздо легче и быстрее.
Незнакомые проекты/технологии/подходы проще .
При работе над отдельными проектами разработчик ограничен ими.
Когда в разных проектах видишь одни и те же вещи, воплощенные в самых разных формах, становится гораздо проще абстрагироваться от деталей и понять общие принципы.
Вы можете увидеть, как работает компания .
Имея отношения сразу с несколькими проектами и всеми разработчиками, вы можете понять, как работает весь отдел и смежные отделы.
Такое видение иногда позволяет дать правильные ответы на нестандартные вопросы о том, какой образ действий в совокупности будет самым простым для всех, кому принадлежит ответственность за то или иное решение и т. д. Вам нужно ставить перед собой задачи .
Завершая проект в качестве разработчика, вы выполняете набор задач, подготовленных кем-то другим.
При управлении отделом не существует технического задания или объема работ. Отдел сам по себе является проектом, и я в нем разработчик, менеджер проекта и владелец продукта.
Решения о том, какие задачи необходимо выполнить, принимаю я.
Нам нужно учить людей .
Часто одно и то же.
Иногда несколько раз.
Роль технического лидера – это, собственно, то, что для этого нужно.
Если в компании есть разработчики, у которых он сам может учиться (к счастью, такие у нас есть), это очень здорово, и к ним имеет смысл относиться с большим вниманием.
Делегированные задачи редко выполняются .
Где-то это связано с ошибками, спешкой, невнимательностью, где-то с непониманием общего видения, где-то дело вкуса.
По большей части вам приходится давать дополнительные указания и отправлять задания на доработку, а в условиях сжатых сроков даже выполнять их самостоятельно.
Я стараюсь сделать так, чтобы это не стало узким местом в процессе.
Полученные результаты
Статья получилась объемной.Надеюсь, это кому-то что-то прояснит. Возможно, кто-то внесет какие-то из этих разработок в свою практику или научится чему-то еще для себя.
Естественно, роль технического лидера будет выглядеть по-разному в каждой компании и каждом отделе, но я выделил те аспекты, которые на данный момент кажутся наиболее значимыми в моей среде.
Спасибо.
Теги: #разработка #Управление разработкой #аутсорсинг #Разработка мобильных приложений #Разработка iOS #Разработка мобильных приложений #Разработка Android
-
Онлайн-Хостинг Quickbooks Отзывы Клиентов
19 Oct, 24 -
Флеш-Приложения Для Iphone
19 Oct, 24 -
Отключение Горячей Воды В Москве
19 Oct, 24 -
Анализатор Успеха Идей
19 Oct, 24
