Я техлид. Що робити?

Більше року я займаю посаду технічного лідера своєї компанії, і хочеться поділитися напрацюваннями по темі. Має сенс уточнити: я веду відділ iOS-розробки з 10 чоловік у компанії-аутсорсере. В моєму випадку посада передбачає оптимізацію роботи відділу, розподіл завдань між розробниками і активності, пов'язані з програмуванням. Трохи розповім про свій досвід, напрацювання і умовиводах. Стаття може бути корисна насамперед новачкам на аналогічній посаді, або тим, хто на неї мітить. Якісь практики і принципи можуть бути перенесені на звичайну розробку, на інші платформи або навіть інші спеціальності.

Обов'язки
Щоб зрозуміти, чим конкретно мені доводиться займатися, має сенс почати зі списку обов'язків. У них входять:

  • Обов'язки розробника:
    • Написання коду, рефакторинг
    • Рев'ю коду

    • Консультування фахівців інших відділів з технічної частини
    • Оцінка трудомісткості проектів і окремих завдань
    • Участь у наймі
  • Оптимізація роботи відділу:
    • Підвищення технічного досвіду розробників
    • Визначення порядку виконання стандартних активностей

    • Напрацювання готових рішень
    • Введення нових співробітників у відділ
    • Утилізація часу простою розробників
  • Розподіл завдань:
    • Завдання на проектах, що вимагають тимчасового втручання
    • Завдання всередині відділу

    • Оцінки проектів для продажу
    • Консультування менеджменту в частині розподілу розробників між проектами
Тут наведені основні обов'язки; частина заходів, специфічних для нашої компанії, опущена. Більшість розробників виконує стандартний набір активностей і має гарне уявлення про них, тому хочеться зробити наголос саме на веденні відділу.

Оптимізація роботи відділу
У чому вона в принципі може полягати? Очевидно, поліпшення швидкості і якості виконання стандартних завдань. Здавалося б, зазвичай буває або одне, або інше, але тут важливо нарощування досвіду — компанія реалізує велику кількість проектів, в процесі роботи вирішуються одні і ті ж завдання, і з часом можна виділити найбільш вдалі і логічні рішення і навчити відділ ними користуватися. У цьому полягає глобальна ідея оптимізації.

Пройдемося по коштах, які дозволяють це в певній мірі реалізувати.

Документування

Стандартні активності можна і потрібно документувати. Записана інформація краще запомненной з багатьох причин:

  • Вона представляється в одному і тому ж вигляді для всіх
  • Її подання завжди буде повною і правильною, без «зіпсованого телефону»
  • Її вивчення витрачає час тільки вивчає
  • Вона не втрачається ні з-за поганої пам'яті, ні при недоступності окремих людей
  • Її завжди можна освіжити
  • Вона не розсинхронізується при зміні
  • У процесі фіксації і доопрацювання детально продумуються всі важливі аспекти
  • Дії в рамках інструкцій можуть підлягати автоматизації
  • … можна продовжувати
Має сенс документувати все, що виконується багато разів. Це можуть бути гайдлайны для коду, порядок виконання оцінок чи проведення співбесід, правила роботи з репозиторіями або баг-трекером — що завгодно, що потрібно робити постійно і чому доводиться навчати нових людей знову і знову.

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

Вкрай важливо тримати документацію в актуальному стані, так як інакше робота над нею буде просто тратою часу. Це не принесе користі, так як довіри до неактуальним джерелами інформації не буде, ними знову ж таки не будуть користуватися, а час буде витрачено. В ідеальному світі брати участь у розвитку загальної документації повинен весь відділ — тоді всі будуть розуміти, яка саме документація наявна, де її шукати, як їй поділитися, а сама інформація буде актуальною.

Не закликаю розводити бюрократію і покривати інструкціями кожне дрібне рух, так як це неефективно. Але найосновніші речі має сенс визначити, зафіксувати і почати доносити до людей.

Переносимий код

У разі мобільного аутсорс-розробки ми маємо відносно невеликі за розміром і терміну життя проекти, на яких більша частина функціоналу схожа, або взагалі не повторюється. В цьому випадку можна створити базу коду, стерпного між проектами. Це можуть бути стандартні утилітарні функції, якісь контроли, окремі шари або щось ще.

Якщо відділ має свою історію, там в будь-якому випадку вже є якісь напрацювання, які переносяться між проектами просто як окремі файли. Такий варіант простіше, але код допрацьовується під потреби одного проекту, а в разі перевикористання його доопрацювання можуть різнитися. Виділення стерпного функціоналу в окремі репозиторії дає можливість продуктивніше розвивати і стабілізувати рішення. Використання менеджерів залежностей додатково скорочує час на переиспользование, хоча і збільшує час на підтримку і вносить свої обмеження.

Якщо спочатку бази коду немає, розробникам може бути незвично і незручно виносити рішення в окремі репозиторії, бо «навіщо мені напружуватися, якщо і так працює»? Можливо, комусь доведеться пояснювати, що стратегічно з точки зору роботи компанії так буде краще. З часом процес входить у звичку, не створює проблем і не викликає нерозуміння, тому що сприймається, як належне.

Автоматизація

Деякі стандартні активності піддаються автоматизації. Це спрощує рутинні дії, прискорює роботу, знижує людський фактор і іноді привносить можливості, які в ручному режимі практично не реалізовуються.

Стандартний приклад: автоматизація процесу збирання дозволяє сильно (іноді майже до нуля) знизити витрати на підготовку білдів і впровадити в процес статичний аналіз або тестування в обов'язковому порядку (маю на увазі, що можна заборонити збірку без успішного статичного аналізу).

Інший приклад: згадавши про специфіку відділу, можна говорити, що піддається автоматизації процедура старту проекту. У нашому відділі застосовується шаблон, який може згенерувати початковий вміст репозиторію зі структурою проекту, налаштованої під всі гайдлайны, а також з налаштованими git і continuous integration. Його застосування значно спрощує і прискорює старти нових проектів.

В цілому, найпростішим випадком автоматизації можна вважати створення різних шаблонів для документів, коду або чого б то не було ще.

Однаковість

При розробці час найчастіше втрачається на занурення в проекти, так як ті можуть бути по-різному влаштовані, а одні й ті ж завдання можуть з разу в раз вирішуватися по-новому без видимих на те причин. Заступаючи на новий проект, де все в черговий раз зроблено по-своєму, розробник витратить певний час на вивчення інструментарію. Якщо у нього за плечима більше десятка проектів, різниці не буде — він буде вже приблизно уявляти, як можуть вирішуватися стандартні завдання. Якщо ж великого досвіду немає, час буде витрачатися. Тут можна заощадити, привівши розробку до єдиного вигляду.

Для досягнення однаковості проектів застосовується все, що вже перераховано: загальні правила, база рішень типових завдань, автоматизація. Використовуючи їх, можна зробити проекти певною мірою схожими і зрозумілими для нових розробників.

Не варто при цьому надмірно старатися — проекти не обов'язково повинні бути схожі, як дві краплі води. Експерименти з інструментами і архітектурою важливі як для веселощів нарабатывания досвіду, так і для дослідження потенційних нововведень. Має сенс системно експериментувати, відштовхуючись від єдиної бази.

Ефективність рішень

В ідеальній картині світу потрібно стежити за тим, чи виправдає себе те чи інше рішення. Переваливши за певний поріг, витрати на його підтримку можуть перевищити вигоду. Найкращим і єдиним об'єктивним показником тут є час. Якщо є можливість хоча б іноді подивитися зрізи витрат на підтримку всього використовуваного набору, наприклад, по місяцях, це може допомогти краще зорієнтуватися. У мене, на жаль, часу не вистачає, і доводиться все визначати на око. До того ж, деякі потенційно неефективні рішення іноді стає реально містити, завдяки раптово звільнився розробникам. Реальна розробка в цьому плані може відрізнятися від логічною теоретичної.

Збільшення кількості використовуваних інструментів та обсягів документації може зробити занадто складною підтримку всіх напрацювань або навіть їх застосування. Наприклад, забути про правилі з 50ти куди простіше, ніж про одному з 5ти. Знаходження балансу між функціональністю і складністю з цієї точки зору — не сама тривіальна задача. Не можу сказати, що зміг знайти цей баланс і забезпечити використання напрацювань в повній мірі.

Навчання

Багато часу я витратив на створення системи навчання розробників. Побудувавши якісну систему навчання, можна вирішити відразу кілька завдань:

  • Підвищення технічного досвіду розробників
  • Донесення інформації про наявність інструкцій і готових рішень
  • Забезпечення допусків до типових активностей
  • Напрямок росту розробників в правильну сторону
  • Раціональне використання часу простою
На даний момент система має вигляд:

  • Більше десятка ступенів, від самих азів до хардкору
  • Загальний обсяг інформації приблизно на пару років вивчення
  • Ступені включають тестові завдання, інструкції і теоретичну частину
  • Прийняття ступені здійснюється в два етапи:
    • Виконання тестових завдань, з рев'ю коду
    • Інтерв'ю з інструкцій і теоретичної частини

  • Прийняття ступенів здійснюється практично безперервно, мінімальний інтервал між інтерв'ю — один тиждень
  • До системи прив'язані допуски до активностей
Таким чином, розробники безперервно перебувають у процесі зростання, причому система побудована так, щоб спочатку закрити потенційні дірки в знаннях, а потім навчити розв'язувати типові задачі, тобто будується виключно на матеріалі, що застосовується постійно.

Ступені включають інструкції для виконання тих чи інших активностей (написання коду, старти проектів, оцінка), і по мірі закриття ступенів розробники отримують відповідні допуски.

Починається навчання з вступної щаблі, яка містить гадлайны коду, інструкції по роботі з системою контролю версій і баг-трекером, а також самі ази програмування. Прийшовши в компанію, розробники допускаються на проекти, вже відзвітувавши про знання того, як ми працюємо, і мінімальному наборі навичок, а також виконавши тестовий проект і пройшовши у процесі відповідне рев'ю, тобто, маючи повне уявлення про процес роботи.

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

Розподіл завдань
Структура нашої компанії реалізована так, що технічний лідер не управляє розподілом розробників. Участь у формуванні команд має консультативний вид: кого з ким краще ставити, чи потягне та чи інша команда проект і т. д.

В мої обов'язки входить лише забезпечення виконання завдань, які не належать до активних проектів. Якщо є відносно вільні люди, їм можна передавати оцінку трудомісткості додатків для продажу або, наприклад, невідкладні завдання на формально припинених проектах, де зовсім нікому їх виконати, або внутрішні активності відділу або щось ще. Якщо вільних ресурсів немає, потрібно виконувати все самому.

Передача завдань і проста, і складна — потрібно перевіряти, хто вільний на даний момент, особисто звертаючись до розробників та менеджерів проектів. Мені поки не вдалося придумати нічого ефективніше звичайного діалогу, хоч чуття і підказує, що повинна бути якась можливість зробити це простіше і прозоріше. Єдине, що вдалося придумати для спрощення комунікації — загальний чатик для розробників. Іноді, написавши туди, можна дізнатися, що хто-небудь раптово вільний і може виконати необхідну роботу.

Сам процес делегування завдань і контролю виконання — не найпростіша область, і мені вдалося освоїти тільки самі його ази, тому тут якихось одкровень не буде. У всіх завдань є ступінь передання — наскільки ефективною і безпечною може бути її делегування. Завжди можна віддати якусь просту задачу, яку буде складно зробити так, щоб вона сильно щось зіпсувала. Завжди краще бути готовим до гірших сценаріїв, хоча все залежить від рівня виконавця. Якщо рівень розробника високий і є довіра, можна передавати великі і складні завдання або навіть формування спільного бачення щодо того чи іншого питання. Вимоги до виконання переданої завдання завжди потрібно позначати максимально точно, щоб виключити елементарні помилки і знизити можливість некоректного трактування. Також не можна забувати про перевірку результатів.

Ясно, що по мірі зростання відділу потрібно розгортати структуру, в якій обов'язки будуть додатково розподілятися на постійній основі, або розбивати один цілий відділ на декілька менших за розміром але в моїй практиці до такого не доходило.

Як все це осилити
Якщо окинути поглядом перераховане і уявити, яку кількість часу потрібно на кожну з цих активностей, стане зрозуміло, що посада передбачає багато завдань. Це не будні розробника, коли у тебе в звичайний день одна-дві, максимум п'ять активностей однакового типу. Мій стандартний день включає 5-10, а іноді і 15 завдань, і їх тип може сильно відрізнятися. Мозок працює зовсім по-різному, коли тобі доводиться лагодити складний баг, вивчати нову технологію або створювати, планувати і пріоритезувати виконання завдань. Оскільки більшу частину часу я не прив'язаний до одного проекту, а займаюся відразу декількома, необхідно щодня по кілька разів швидко вгружать в голову і вивантажувати великі обсяги разнотипной інформації.

Так як від природи мій мозок не володіє видатними параметрами і сам по собі не тягне таке навантаження, що доводиться йому допомагати. Впевнений, що в розумних книгах по управлінню часом всі ці практики вже придумані, але я не приділив достатньо часу їх вивчення, так як моїм пріоритетом було і залишається розвиток у бік програмування.

Найгірше в моєму випадку справляється пам'ять, тому частина практик спрямована на заміну пам'яті мозку сторонніми засобами і звичками. Друга група передбачає залучення інших людей до виконання активностей. Почнемо з останньої і непомітно перейдемо на першу.

Делегування. Про нього вже дещо сказав. При нестачі часу потрібно намагатися по максимуму передавати роботу іншим.

Залучення розробників на рівні культури. Якщо сформувати у відділу хороші звички, частина активностей може виконуватися навіть без відома технічного лідера. Наприклад, помилки в переносимом коді можуть виправлятися розробниками в рамках звичайного виконання завдань на проектах.

Чеклисты. Щоб не забувати про порядок дій, можна скласти їх списки: на звичайний робочий день, на виконання тієї чи іншої активності, на окрему задачу або на випадок певної події (наприклад, оновлення якого-небудь інструмента). З часом необхідність у чеклистах відпадає, оскільки їх дотримання входить у звичку, але спочатку вони можуть бути дуже корисні.

Нагадування. Коли я виконую завдання, то намагаюся залишити собі нагадування по кожній дрібниці на випадок, якщо раптом відволікся або забуду щось в ході роботи. Це можуть бути «TODO» в коді, записки в окремому документі або на аркуші паперу. Потрібно по максимуму страхуватися від того, що в процесі роботи щось буде забуто і не дороблено.

Дисципліна. Виконувати завдання потрібно у повному обсязі, щоб не потрібно було більше про них згадувати. Статуси в системі управління проектами потрібно виставляти своєчасно, списувати час потрібно відразу ж після закінчення роботи над завданням, тому що, виконавши десяток різних завдань і вичерпавши ресурси мозку, легко забути, що ти взагалі за сьогодні зробив. А якщо задач було багато, і вони були невеликими, про них взагалі легко забути, і тоді вийде, що робочий час ніби пішло в нікуди. Якщо завдання виконувати відразу в повній мірі, у вашому пулі паралельних активностей їх буде значно менше, ніж було б, якщо б доводилося повертатися до вже виконаним.

Відмова в комунікаціях. Безліч обов'язків передбачає безліч комунікацій. Відповісти на листи і повідомлення в месенджерах можна, закінчивши поточну активність. Найсильніша комунікація — особиста, і вона найважче піддається постановки в чергу. Коли до мене під час виконання завдання підходять люди, частенько доводиться говорити їм, що я зайнятий і не можу розмовляти. В іншому випадку контекст думок буде постійно губитися, і після розмови доведеться все згадувати заново. При певній кількості комунікацій, якщо в них не відмовляти, продуктивність при виконанні складних і об'ємних завдань буде просідати, іноді майже до нуля. Розгорнути людини, який підійшов до тебе особисто, може бути непросто, але при великій кількості задач це необхідно.

Перелік завдань

На мій погляд, найважливіший інструмент, гідний окремого пункту. Якщо ви не можете тримати в голові всі свої завдання, треба вести їх облік. Тут необхідно щось більш вільне, чим баг-трекер. Я використовую простий текстовий документ.

Коли надходить нове завдання, вона просто додається до списку так, щоб зберігалася приблизно черговість, залежно від пріоритетів. Коли активна завдання закінчується, я повертаюся до списку, вибираю найбільш пріоритетний пункт і беруся за нього. Так час не витрачається на пошуки завдань.

При необхідності можна оцінити, скільки часу буде потрібно на кожну активність у списку і визначити терміни їх виконання. Такі оцінки, щоправда, не завжди коректні, оскільки завдання надходять у випадковому порядку, і заздалегідь невідомо, коли і скільки їх ще з'явиться. Втім, з цим теж можна боротися, заклавши певний час на день, на раптову зайнятість і даючи песимістичні оцінки.

В окрему секцію списку у мене виділені пункти, що стосуються перевірки виконання переданих активностей. Якщо завдання виконує інша особа, необхідно періодично перевіряти статус, інакше вона може просто загубитися, так як мало хто з розробників піклується про те, щоб нічого не забувати.

Для когось ведення простого списку завдань може виглядати, як «велосипед», але це проста і реально робоча практика, яка допомагає зберегти час і не забути про завдання. Принаймні, радикально знизити кількість забутих.

Відчуття
Начебто, описав, чим я займаюся, і як з усім цим справляюся. Можна додати трохи лірики про власні відчуття від роботи. Можливо, комусь це допоможе прийняти рішення про те, чи варто цим займатися.

Результат не помітний. Якщо я роблю проекти, то це більше відноситься до старту, і в підсумку його роблять інші люди. Навчання розробників безпосередньо відстежити неможливо. Щоб зрозуміти, чи працює те чи інше рішення, потрібно виконати одні і ті ж завдання з ним і без нього, зняти статистику витрат на його розробку і підтримку, і зробити висновки. На такий аудит в наших умовах часу немає і не може бути. У підсумку, відстежити, наскільки вірні або невірні мої дії, неможливо. Пред'явити результати моєї роботи в чистому вигляді, відповідно, теж не можна. Це не додає моралі.

Проекти загубили обличчя. Коли розробник робить хоча б один повноцінний реліз програми, він починає добре орієнтуватися в його поведінці. Коли мова йде тільки про старт програми, рев'ю або фікс кількох складних багів, запам'ятати проекти не виходить. Навіть технології здаються скрізь однаковими.

Прості завдання дістаються розробникам. Братися за прості речі доводиться вкрай рідко. Мені дуже подобається займатися простий версткою стандартних екранів і підганяти пікселі і кольору, воювати з проблемами UIKit, але останнім часом велика частина завдань має відношення до побудови архітектури прикладних програм.

Коротка пам'ять погіршилася. Перетравлення великих обсягів інформації спочатку перевантажувало мозок. Я почав його розвантажувати, і це призвело до того, що він в принципі відвик запам'ятовувати те, що не записано. Можливо, це вірно тільки для мого випадку.

Зміна контексту роботи стала простіше. Як з'ясувалося, цей момент піддається тренуванню. Мозок звик до постійним перемиканням між завданнями і справляється з ними куди легше і швидше.

Незнайомі проекти/технології/підходи даються простіше. Займаючись окремими проектами, розробник ними обмежений. Коли бачиш одні і ті ж речі, втілені в безлічі різних форм на різних проектах, стає набагато простіше абстрагуватися від деталей і зрозуміти загальні принципи.

Видно, як працює компанія. Маючи відношення до кількох проектів і ко всім розробникам відразу, можна зрозуміти, як працює весь відділ і суміжні відділи. Це бачення іноді дозволяє дати правильні відповіді на нестандартні питання про те, який порядок дій буде найпростішим для всіх в сумі, до чиєї ведення відноситься те або інше рішення і т. д.

Потрібно самому ставити завдання. Коли виконуєш проект, будучи розробником, то виконуєш набір завдань, підготовлений кимось іншим. При веденні відділу немає ніякого ТЗ або скоупа робіт. Відділ — це сам по собі якийсь проект, і я в ньому і розробник, менеджер проекту, і власник продукту. Рішення про те, які завдання потрібно виконати — на мені.

Потрібно вчити людей. Часто одного й того ж. Іноді по кілька разів. Роль технічного лідера, власне, для цього і потрібна. Якщо в компанії є розробники, у яких зможе повчитися він сам (у нас такі, на щастя, є), це дуже здорово, і до них має сенс ставитися з великою увагою.

Передані завдання рідко виконані до кінця. Десь це обумовлено помилками, поспіхом, неуважністю, десь нерозумінням спільного бачення, десь смаківщиною. Здебільшого доводиться давати додаткові вказівки і відправляти завдання на доопрацювання, а в умовах гарячих термінів і зовсім самостійно допрацьовувати. Намагаюся стежити, щоб це не ставало «вузьким місцем» процесу.

Підсумки
Стаття вийшла об'ємною. Сподіваюся, кому-небудь вона щось прояснить. Можливо, хтось привнесе в свою практику що-небудь з цих напрацювань або винесе для себе щось ще. Природно, у кожної компанії і кожному відділі роль технічного лідера буде виглядати по-своєму, але я висвітлив ті аспекти, які на даний момент здаються найбільш значними в моїх умовах. Спасибі.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.