Як подружити розробника і менеджера

Всі компанії, а тим більше проекти, різні: відрізняються завдання, підходи і команди. Їх об'єднує лише одне — напруженість між менеджерами і розробниками. В попередній статті я писав про те, що значить бути лидом (а це багато в чому означає бути менеджером). Напевно, такий досвід дозволяє інакше поглянути на ситуацію і спробувати копнути тему глибше, ніж «технарі проти гуманітаріїв» або «виконавець проти керівника». А розібравшись, подумати, чи варто воно того, чи ні.

У будь-якій статті на DOU про менеджерів легко знайдеться хоча б один з наступних коментарів:

«Scrum не потрібен, адже діди п'ятирічками нейромережі на перфокартах писали».
«Менеджери — дармоїди. Тільки вимоги дайте, а далі ми самі».
«Мітинги — зло. Домовляйтеся без мене, але щоб по-моєму вирішили».
«Софт-скіли для софт-людей. Краще про код думайте».
«JavaScript мову, Front-End не програміст».

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

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

Ілюстрації Каталіни Маєвської

Війна світів

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

У той же час менеджер працює з людьми, які змінюють думки, брешуть, помиляються, несуть нісенітницю і вірять в гомеопатію. При цьому менеджер повинен все це вислухати, зібрати воєдино, відсіяти дурницю і придумати, як на цьому заробити гроші. Таким чином, у світі людей нічого не визначено , а можна спиратися лише на якісь дані, пару думок і своє чуття. Начебто все круто, але завтра конкурент зарелизил нову фічу — і ти в прольоті. А програмісти кажуть тобі, що «антиэкранирование відбувається з-за того, що переносники сильної взаємодії, якому піддані глюони, самі володіють колірним зарядом і в процесі руху як би „породжують нові глюони з вакууму“, посилюючи тим самим взаємодія» (приблизно так для менеджерів звучать міркування програмістів про неможливість зрушити кнопку на 2 пікселя вліво).

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

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

— Один, потрібна таблиця з кошенятами!
— Не питання. А скільки планується кошенят в системі?
— Ну 5-10... А може, і 1000.
— Хм, 1000 кошенят... Треба прикрутити пагінацію, зробити ліниву підвантаження, перевірити на різних девайсах і швидкостях... Потрібен місяць.

Зазвичай далі слід неперекладна гра слів, суть якої зводиться до стискання естімейта благаннями, погрозами і різними стимуляциями. Причому тут конфлікт детермінованого та імовірнісного світогляду? Притому, що сторони діалог-то вели, але не розуміли один одного.

По-перше, величезний розкид за вихідними даними у вимогах. Так пара десятків кошенят або пара тисяч? Звідки ці цифри? Оскільки менеджер живе в імовірнісному світі, він бачить можливість того, що кошенят буде саме 1000. Навіть якщо така людина буде один, а у решти мільйона користувачів буде від 5 до 10 кошенят. Чому б не зробити продукт хорошим для всіх?

А що почув програміст? Він почув про ліміт в 1000. Але ж коли він буде писати код, то не зможе тільки трохи підтримувати певний кейс. Його треба буде або підтримувати, або ні. Відповідно, він проектує рішення під 1000 кошенят, хоча в 99% випадків їх буде на кілька порядків менше. Звідси і місяць.

При цьому варто лише трохи змінити діалог, і ця проблема зникне сама собою:
— Потрібні кошенята в таблиці!
— О'кей, скільки їх?
— Від 5 до 10. А якщо 1000, то наскільки довше буде?
— Ну для 5-10 я зроблю за 3 дні, а для 1000 — за місяць.
— Багато котів в одній таблиці до біди. Роби для 5-10, а там подивимося.

Я дуже часто помічаю, як проста фраза програміста: «А це реально потрібно? Без цієї маленької фічі ми все зробимо за день, а з нею — мінімум за тиждень» — могла б заощадити багато часу і грошей, але вона просто не звучить. Виходить, програмісти погані? Немає. Як я писав вище, сторони повинні порівну ділити дискомфорт. І нормальний менеджер повинен сам дізнатися, з чого складається естімейт і що доставляє найбільше проблем, і в кожній конкретній ситуації давати саме ті вихідні дані, які оптимальні для неї. А програміст повинен йому в цьому допомагати, підказуючи, що можна викинути, заощаджуючи при цьому ресурси, а де дешево і сердито зробити з запасом.

Наведений приклад демонструє очевидну річ: в більшості проблем винна комунікація. Про неї далі.

Міс комунікація

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

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

Деталі імплементації

Розробники, увагу: далі йде жорстока правда! Менеджерам абсолютно, тотально, неймовірно і глибоко фіолетово плювати на те, як ви реалізуєте фічу в технічному плані. Їх цікавить інше: наскільки швидко, якісно і надійно ви її зробите. І ця усвідомлена невігластво — не примхи або лінь, а необхідність. Це ваша робота, а їм навіщо влазити в неї? У них вистачає. Адже ви й самі бесітесь, коли до вас лізуть з порадами.

Це рідко виступає великою проблемою, але вона забирає багато часу, особливо на мітингах, а іноді стає причиною просто-таки дитячих образ розробників (що їх не слухають, а значить, не поважають). Тому ви, програмісти, залиште технології програмістам, бо вони нецікаві менеджерам. А ви, менеджери, якщо хочете бути не погоничами, а улюбленими панами/панями, дайте іноді кодерам висловитися. Зробіть розумні очі, задайте пару уточнюючих запитань і скажіть в кінці: «Круто!» Вам же з ними потім працювати.

Синкапы

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

Звідси ці вічні питання:

— «На якому ти етапі?»
— «Встигаєш вкластися в естімейт?»
— «Вийде залити сьогодні на стейдж?»

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

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

Назад у майбутнє

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

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

Так виникають ситуації, в яких кожен намагається перетягнути іншого в свою тимчасову лінію:

тестувальники смикають програмістів в минуле («Можеш глянути? Я тут клікаю завдання, яке ти тиждень тому рушив у QA, і...»);
програмісти тягнуть менеджерів в даний («Я тут читаю acceptance-критерії, і це якась дичина. Чому...»);
а менеджери тягнуть програмістів в майбутнє («Потрібно, щоб ти глянув на цю фічу і приблизно оцінив. І що значить дичину?!»).

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

«Ей, ти не зайнятий?»

Стільки на цю тему сказано, а ніхто, схоже, не слухає. Уявіть, що ви намагаєтеся заснути, і в той момент, коли ви майже відійшли у світ, де долар по 100, а сири з 10, вас трясе за плече і запитують: «Вибач, ти вже спиш?». І так разів 10 за ніч, причому щоночі. Розробникам це відчуття знайоме: те ж саме вони відчувають, коли входять в стан потоку, а їх висмикують фрази: «Ти зараз зайнятий?»

Чесно, я не фанат всіх цих солодких теорій про те, що програміст — це червонокнижна тварина, навколо якого треба водити хороводи і співати йодлем. Але є у нього одна особливість: для продуктивної і якісної роботи йому потрібен час. Правильний час — безперервне, як мінімум 3 години, протягом яких він зможе зосередитися на одній конкретній задачі. Обід, синкап, а іноді навіть звичайний питання про погоду ставлять крапку на поточному часовому інтервалі, і його потрібно відраховувати заново. А тут є проблемка.

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

Вирішити це досить просто в 2020 році — з допомогою месенджерів. Менеджери, тестувальники, а особливо інші розробники, не смикайте людини наживо, навіть якщо він сидить на сусідньому стільці! Домовтеся про зручному всім каналі зв'язку і пишіть туди. Буде час, він гляне і відповість. Ні — значить, чекайте або смикайте, але будьте готові привести вагомі аргументи на користь такого рішення.

Cloud microservice blockchain multi-tenant AI solution

Майже кожен менеджер, якого я знаю, у своїй промові до місця і не до місця вставляє різні баззворды. Мені здається, їх на це надихають розробники. А менеджери думають, що так з останніми буде простіше знайти спільну мову. Ну і звучить круто. Однак є нюанс: треба все ж таки розуміти, що ти взагалі несеш! :)

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

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

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

Не найгіршим варіантом буде, якщо технічний спеціаліст, почувши термін від менеджера, просто уточнить, чи правильно він його зрозумів. Але адже не кожен раз так робити? Навіть у моїй практиці було багато ситуацій, коли ми поговорили з менеджером, начебто все вирішили, а потім виявилося, що говорили про різне! І одного гуглу відомо, скільки людино-років спалюється подібним чином: коли хтось просто захотів використовувати термін, який не до кінця розуміє.

Якщо ви менеджер і вирішили використовувати в розмові з програмістом одне з цих слів: кеш, блокчейн, микросервисы, АПІ, інтерфейс, бек-енд або клієнт, то краще поясніть звичайними словами, що ви маєте на увазі. Інакше є великий шанс, що ви отримаєте зовсім інше. Та й взагалі, з розумними словами не перегинайте: навіть програмісти часто один одного не розуміють, і те, що досі виходять статті з «простими» розшифровками SOLID'а, яскравий тому приклад.

Мир, праця, скрам

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

Навіщо програмісту «дружити» з менеджером? Подобається нам це чи ні, але беруть нас на роботу менеджери (нехай і опосередковано — через інших програмістів), підвищують нам зарплату і звільняють вони ж. Знати, що вони цінують у розробників і як будувати з ними продуктивні взаємини, — прямий шлях до швидкого зростання, блискучій кар'єрі і зарплати вище ринкової. Важливо розуміти, що я не пропоную підлабузнюватися і запобігати перед ними (це вже вибір особисто кожного). Я лише кажу, що з більшою ймовірністю ти візьмеш на роботу приємного тобі людину, яка розуміє, що ти робиш і готовий в міру своїх сил тобі в цьому допомагати або, як мінімум, не заважати. Його ж ти підвищиш і йому запропонуєш зайву тисячу, щоб утримати. Тому програмісту «дружити» з менеджерами дуже корисно.

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

Крім всього цього, є досить проста причина жити дружно: так приємніше. Адже круто працювати в дружньому колективі, де всі один одного розуміють, підтримують і допомагають? Може, я і наївний, але прагнути до цього варто.

Тому закінчу цитатою Джима Джеффріса, яка у своїй простоті чудово підсумовує те, до чого я так довго веду: «Try not to be a cunt, and if you do that every day, you'll be a good person».

Так що будьте good person, а решта додасться. Ну а якщо не згодні, пишіть в коментарях.

Класних вам проектів і легких апрайзалов! До нових віртуальних зустрічей!

Опубліковано: 12/02/20 @ 11:00
Розділ Різне

SEO Блог