Вітаю тебе, мандрівнику, в неофіційному туторіалі до ігрового класу «програміст».

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

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

От і доводиться гравцям розбиратися у всьому самим. А час від часу ще й ділитися знайденими закономірностями з колегами. Звідси і цей туторіал.

Ілюстрації Уляни Патоки

Клас «програміст» — це один з небагатьох у грі магічних класів. Персонажі цього класу підбирають закляття певного формату і звертаються з ними або до магічних предметів у них на столах, або до примарних, напівбожественних (чи демонічних!) сутностей десь далеко у «хмарах».

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

Натомість я хотів би зосередитися на прокачці персонажа цього класу. І тут відразу перша проблема.

Що саме називати прокачкою?

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

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

Мультиплікативний коефіцієнт.

Уроки множення

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

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

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

Середній гравець через кілька років прокачки має коефіцієнт одиничку: доклав зусиль — проект злетів; трохи полінувався, і деякі частини вже починають провисати. А от потім починається справжня магія.

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

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

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

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

Початкові стати

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

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

Та менше з тим, міняти щось у початкових статах тобі очевидно вже пізно.

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

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

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

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

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

На перший погляд, існування таланту — сумна і несправедлива історія. Одним усе, а іншим — нічого. До того ж талант допомагає і в навчанні, а початкові успіхи можуть мотивувати до подальшого зростання. Тобто і качатися талановитим зазвичай простіше. Але є один нюанс.

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

Ну і найсмішніше. Зазвичай люди категорично не здатні відрізнити результат, отриманий за допомогою таланту, від результату, отриманого через прокачку. Пам’ятаєш, в опитуванні про піаніста музика була тією ж!

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

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

10 000 годин

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

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

Що ж, звісно, є. Тільки не один до одного. Так само як мультиплікативний коефіцієнт визначає зв’язок між зусиллями і отриманими результатами, його похідна, коефіцієнт навчання, визначає ефективність самої прокачки.

Хороші новини: коефіцієнт навчання менше залежить від початкових статів. Набагато більше на нього впливають правильно вибрані техніки і стратегії. Так-так, те саме горезвісне «вміння вчитися», яке обіцяють навчальні заклади, натякаючи, що ніяких інших корисних знань ти там не отримаєш. (Вчитися там, втім, теж не вчать. Доводиться у всьому розбиратися самому.)

Так от, перше і найголовніше правило навчання — зворотний зв’язок.

Очевидно. Якщо ти робиш щось неправильно і ніхто тебе не виправляє, сенсу з твого «досвіду» практично нема. Навіть гірше: ти можеш неправильно «набити руку», і тоді перевчатися буде важче, ніж вчитися з нуля. (Саме тому, до речі, деякі компанії надають перевагу розумним випускникам над сформованими в інших обставинах спеціалістами: їх перевчати простіше.)

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

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

Другий тип зворотного зв’язку — це оцінка Майстра. Хтось більш досвідчений, з вищим мультиплікативним коефіцієнтом, здатен не тільки відкоригувати вибрану стратегію і допомогти отримати результати, але й набагато пришвидшити процес навчання, запускаючи ланцюгову реакцію. Більшість наукових відкриттів були зроблені не одинаками, а так званими школами, де більш досвідчені учасники тягнули за собою новачків, які потім горизонтальним зворотним зв’язком підвищували мультиплікативний коефіцієнт до небес. Хочеш швидко качатися — будь поближче до Майстра. Хоча б у твіттері на нього підпишись, ну?

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

Правильний вибір квестів

Що ж, нехай зі зворотним зв’язком ми розібралися, але треба ще ж вибрати, що саме робити, щоб цей зворотний зв’язок отримувати. Безумовно, потрібно виконувати квести, або по-простому, йти на роботу.

І тут тебе може чекати перша пастка на твоєму шляху: так звані сходи Ешера.

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

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

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

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

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

І ключова причина помилки — нерозуміння різниці двох понять: «важко» і «складно».

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

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

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

Хороші менеджери дають складніші, високорівневі завдання, результат яких напряму залежить від мультиплікативного коефіцієнта. Хоч-не-хоч прокачаєшся, навіть якщо і наробиш у процесі помилок. Особливо, якщо наробиш помилок — такий досвід цінується вдесятеро більше. Blameless post-mortems, усе таке.

Вміння бити штрафні

То що, головне знайти хорошого постачальника квестів, робити все, що він скаже, і прокачка гарантована? — запитаєш ти. Ну, не зовсім.

Навіть ідеальні квести не будуть ідеально підходити під той набір навичок, які тобі треба прокачати. Навички, які тобі потрібні, будуть траплятися в роботі рідко, але матимуть натомість високу ціну. І тоді «просто працювати» для їх прокачки вже не вийде.

Про Андрія Шевченка його колеги по збірній говорили, що після кожного тренування він лишався сам на полі ще на півгодини і просто вчився бити штрафні. З різних точок і положень, методично і раз за разом відправляв м’яч у ворота, коригуючи удар ногою на основі результату. Олександр Шовковський так само окремо тренував відбиття пенальті.

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

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

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

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

***

Ну й наостанок. Найбільша помилка, яку може зробити гравець-початківець, — це піддатися на спокусу «zero-playing game».

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

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

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

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

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

І при цьому всьому — «міняти час на гроші» і переживати про чергову безглузду плашку за вбивство чергової порції щурів? Серйозно?

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

Щасти тобі у пригодах, мандрівнику, і хай бережуть тебе Тюрінг і Лавлейс!

Бувай!

Создание собственных продуктов было целью Railsware практически с момента основания (а это уже 13 лет). Сейчас уже могу сказать, что мы воплощаем задуманное, более того, могу говорить о том, как строить успешные продукты. Мы прошли крайне важный рубеж: показатель регулярного дохода от собственных продуктов достиг 1 млн USD (ARR ― annual recurring revenue). Конечно же, 1 млн USD ARR — это не космические цифры. Это всего лишь этап, и большая игра только начинается. При этом мы стартовали как классический аутсорсинг, трансформировали бизнес-модель в Product Studioи на сегодня развиваем два направления ― сервисное и продуктовое.

Эта статья о том, как мы шли к такому результату и что нужно для того, чтобы создать прибыльный продукт, который любят пользователи. Спойлер: метод проб и ошибок никто не отменял.

From 0 to almost hero, или Немного истории

Сегодня модель нашего бизнеса ― Product Studio, платформа для создания и развития коммерчески успешных продуктов. Мы разрабатываем как собственные продукты, так и продукты для клиентов, применяя одинаковые подходы и инструменты. Продуктовый и сервисный бизнесы могут успешно функционировать в рамках одной компании. Пока что таких примеров не много, хотя некоторые сервисные компании пытаются делать свои продукты. Причина в том, что для сервисного бизнеса качественный продукт редко является ценностью, он зачастую служит способом занять людей на бенче, иногда ― решить внутренние задачи. У такого продукта нет постоянной команды, соответствующего настроя и цели дожать его до победного конца. И результат выходит соответствующий.

Мы пробовали разные бизнес-модели и практически с первых лет пытались быть партнером и соинвестором для нескольких больших продуктов. У нас было два кейса, где владельцы бизнеса находились в США, инвестировали в продукт и осуществляли бизнес-девелопмент. Мы же со своей стороны строили софт, при этом вкладывая деньги. Один из этих проектов с грохотом провалился, и мы потеряли значительную сумму. Но это привело к пониманию того, насколько важно укреплять практические знания во всех аспектах построения продукта, включая продуктовый маркетинг, бизнес-разработку, поддержку и прочее.

Примерно в то же время начали экспериментировать над созданием собственных продуктов. Были увлечены этой идеей и в каждом варианте решения проблем, с которыми сталкивались по ходу работы, видели потенциал для построения продукта.

У нас были десятки прототипов, которые так и остались на стадии proof of concept. Часть из них переросла в проекты для внутреннего использования, в основном для управления операционной деятельностью. Лишь несколько из них реализовались как публичные, хоть и небольшие бесплатные продукты.

Например, сделали пару расширений для Pivotal Tracker ― системы для управления проектами, которой активно пользуемся и сейчас. Оба упрощали работу с пользовательскими историями. Одно из них называлось Booster и было реализовано в виде Mac OS X клиента. Другое — в формате аддона для Chrome, назвали PIRO. У него даже был свой слоган: Your Rocket For Pivotal Tracker Accounts :)

Такие приложения выкладывали в общий доступ. Каждое из них находило благодарных пользователей. То есть отдача была, но полноценными продуктами назвать их нельзя. По-честному, мы делали их «на сдачу», пробуя, пытаясь, но по факту лишь рассеивая свое внимание на эти маленькие эксперименты.

В какой-то момент осознали, что эксперименты — это интересно и увлекательно, но пора сосредоточиться на идеях с потенциалом. Двигать их вперед настолько, насколько хватит энергии и финансовых ресурсов. В итоге сделали ставку на два основных коммерческих продукта: Mailtrap.io и Coupler.io.

Mailtrap

Mailtrap ― приложение для тестирования отправки имейлов. Сегодня это большой самостоятельный продукт, у которого множество именитых клиентов и более полумиллиона пользователей. Начинался он как маленький внутренний сервис еще в те времена, когда наша разработка была больше похожа на ковбойское родео, чем на структурный процесс.

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

Поэтому мы создали своё веб-приложение ― эмуляцию SMTP-сервера, который собирает все входящие письма в виртуальные инбоксы. Оно получило название Mailtrap ― ловушка для писем. Приложение оказалось простым и эффективным решением и стало неотъемлемой частью многих внутренних проектов. Через какое-то время сделали его публичным.

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

В 2014 году произошло то, что мы внутри долго называли Mailtrap 2.0. ― вышла не просто обновленная версия: приложение было перестроено практически с нуля. Чтобы справиться с растущими нагрузками, необходимо было обновить инфраструктуру, а на старом стеке технологий реализовать это было сложно. Также добавили новый функционал для тестирования и дебагинга писем, обновили дизайн.

На тот момент Mailtrap был по-прежнему полностью бесплатным. Но мы начали получать запросы на расширенные лимиты для использования на более крупных проектах. Наша аудитория была готова платить за решение раньше, чем мы стали готовы его продавать. Тем не менее приближались к тому, чтобы превратить Mailtrap в полноценный продукт. Провели мониторинг конкурентов и рынка в целом (о методиках анализа расскажу подробно в следующих статьях). Похожих решений было немного, и нам по-прежнему не хватало данных и опыта для ценообразования. Тогда обратились к пользователям, которых на тот момент было порядка 10 000.

Customer Development ― важная методика для успеха продукта. Продукты создаются для пользователей, чтобы решать их проблемы. Так кто, как не они, подскажут, как сделать лучше? Сейчас регулярно опрашиваем пользователей, собираем фидбек с помощью специализированных приложений и соцсетей, чтобы узнать, как люди используют продукт, какой еще функционал хотели бы видеть, какая модель прайсинга лучше и так далее. Наряду с аналитическими данными эта информация помогает принимать правильные решения в развитии продукта.

Так при помощи аудитории запустили платные планы. Это был крайне важный этап в развитии Mailtrap и наш первый платный продукт. Мы стали относиться к нему гораздо серьезнее, прилагали больше усилий для развития и поддержки, пробовали запускать маркетинговые кампании для привлечения новых юзеров. Это дало свои плоды: за следующие четыре года количество пользователей возросло в 28 раз.

2018 год ознаменовал новый этап для нашего первого платного продукта и компании в целом. Мы приняли решение, что готовы полноценно инвестировать в развитие своих продуктов, поскольку не видим будущего компании без мощного продуктового направления. Тогда выкристаллизовалась модель Product Studio.

Mailtrap претерпел множество изменений. В первую очередь у него появилась выделенная команда: продакт-менеджер, разработчики, дизайнер и маркетолог. Помимо регулярных технических обновлений и улучшений, приложение прошло через несколько итераций обновления дизайна и UI. Мы провели масштабный раунд интервью с пользователями, обновили планы подписки и запустили полноценный маркетинг. У продукта появился блог, который вырос с 0 до 100 000 посетителей за полтора года. Растет и количество пользователей, не так давно оно перешагнуло полмиллиона. Mailtrap ― достаточно нишевый продукт, тем не менее, популярный среди именитых компаний из Top 100 Fortune, а в веб-фреймворке Laravel он рекомендован как тестовый SMTP-сервер по умолчанию.

Сейчас команда Mailtrap выросла еще больше и напоминает мини-компанию ― 15 человек, среди которых уже несколько маркетологов, дата-аналитик и специалист поддержки. Активно работаем над развитием клиентской базы, активацией и конвертацией пользователей и параллельно разрабатываем еще одно направление продукта.

Coupler.io

Второй основной продукт ― Coupler.io ― также был рожден из экспериментов. По сути, это развитие нашего решения для импорта данных из Airtable Importer. Продукт автоматизирует интеграцию данных из различных источников, в том числе Airtable, Jira, Xero, HubSpot, в Google Sheets.

Идея создания Coupler.io тоже пришла из необходимости решить проблемы, с которыми сами столкнулись. В компании многое построено на потоках данных, которые текут из одних систем в другие, сегментируются, затем обрабатываются и так далее. Нам было необходимо как-то автоматизировать процессы. До определенного момента использовали Blockspring, но у него были свои минусы, а затем его вовсе перестали развивать. В поисках качественного и стабильного инструмента вернулись к идее Airtable Importer, расширили и улучшили ее. Существует огромное количество масштабных решений для работы с данными, интеграторов и так далее, но наше ориентировано на потребности малых и средних бизнесов, таких как Railsware.

Опыт внутреннего использования, валидация идеи продукта и анализ рынка убедили в том, что у этого решения есть потенциал. К тому же есть опыт запуска коммерческого продукта, отлаженные процессы, протестированные подходы и знания в продакт-менеджменте и маркетинге.

В результате выпустили аддон для Google Sheets на G Suite Marketplace под названием Coupler.io. Кстати, начальным рабочим названием было Anything Importer. Первый релиз продукта был закрытым: его тестировали с существующими пользователями Airtable Importer. Мы провели множество опросов и интервью, чтобы лучше понять их потребности, и имплементировали еще ряд улучшений. Несколько месяцев спустя, в марте этого года, состоялся публичный релиз.

Сейчас продолжаем уделять особое внимание Customer Development. Отдельную роль в этом процессе играет поддержка. Когда пользователи приходят за помощью, мы стараемся не просто закрыть тикет, а получить максимум информации об их опыте использования продукта, задачах и ожиданиях. Также фокусируемся на онбординге новых юзеров и развитии базы знаний Coupler.io. Выстраиваем четкую коммуникацию с пользователями, и они ценят этот индивидуальный подход.

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

Над Coupler.io также работает выделенная команда инженеров, дизайнеров, продукт-менеджеров, дата-аналитиков и маркетологов. Что важно, с каждым новым продуктом многие процессы происходят намного быстрее и легче, поскольку используем уже собственные отточенные наработки.

Принципы построения успешных продуктов

В результате пройденного пути хотели бы выделить 10 принципов создания коммерческих продуктов.

1. Качественный продукт, который решает проблему реальных пользователей, как ценность и как цель. Значимый критерий успешности продукта — это достижение product/market fit, то есть создание элегантного решения проблем реальных пользователей, за которое они готовы платить. Построение таких продуктов должно стать ценностью для компании: ценности определяют цели. Задавшись целью, сфокусируйтесь на ее полноценной реализации: продукты, которые делаются в качестве дополнительных проектов, вряд ли пойдут дальше концептов.
2. Эксперименты — это часть пути, важная для набора собственного опыта. Сложно создать качественный продукт с нуля, поэтому эксперименты — хороший способ набить свои шишки, попробовать разные методы и подходы без огромных рисков. Важно не застрять на этом этапе, а выбрать в итоге один или несколько концептов, которые сможете целенаправленно и полноформатно развивать.
3. Развитие продуктов из решений для внутренних задач. Это жизнеспособная концепция, поскольку на выходе есть рабочий, протестированный инструмент. Однако, представляя такой продукт внешним пользователям, важно правильно оценить масштаб проблем, которые он решает, и сопоставить с теми продуктами, которые уже есть на рынке.
4. Customer Development. Фидбек пользователей — это ценный источник информации наравне с аналитикой, источник идей. В центре успешного продукта находится клиент — тот, для кого этот продукт создается, — а не только ваши предпочтения.
5. Клиенты как важнейший актив. В продолжение предыдущего пункта: рассматривайте клиентов ваших продуктов как комьюнити пользователей. Они уже лояльны к вам и при выстроенной коммуникации дадут ценный фидбек и выступят тестовой аудиторией для новых проектов.
6. Развитие ремесла (крафта) во всех аспектах построения продукта. Разработка качественного продукта требует глубоких знаний в каждой предметной области, которые закрепляются практикой. Ко всему ― продакт-инжинирингу, маркетингу, техподдержке ― необходимо относиться профессионально, постоянно оттачивая свое мастерство.
7. Универсальные подходы, отточенные практикой. С каждым новым продуктом появляются отлаженные процессы и подходы, благодаря которым можно оптимизировать ресурсы и время вывода продукта на рынок.
8. Концепция T-shape (продуктовое мышление). Это подход, который особенно ценим в коллегах. Он означает сильные компетенции в одной области плюс способность взаимодействовать в смежных дисциплинах. Например, Product Engineer― это специалист с ключевой компетенцией в software development и дополнительными базовыми навыками в продакт-менеджменте и дизайне. Такая совокупность умений позволяет видеть картину в целом и фокусироваться на продукте и решении проблем пользователя.
9. Командная игра, сфокусированная на реализации общей цели.Часто можно услышать, что за классным продуктом стоит классная команда. Команда — это группа специалистов, которые ориентируются на успешный продукт как высший результат.
10. Data-driven подход. Принимайте решения, основываясь на объективных данных. Анализируйте рынок, изучайте своих пользователей, измеряйте результаты, стройте прогнозы. Чем больше правильных метрик соберете, тем меньше ошибок допустите.

В заключение еще раз хочу подчеркнуть, что в рамках одной компании можно успешно развивать два направления: сервисное и продуктовое. Хотя у нас принято классифицировать компании по этим признакам как исключающим. Главное — фокусироваться на том, что действительно важно, и верить в то, что делаешь. Этот первый 1 млн USD (ARR) на собственных продуктах ― подтверждение того, что движемся в правильном направлении, и стимул развиваться дальше.

Кто бы мог подумать, что такое может произойти? Пандемия коронавируса, повсеместный карантин и, как результат, тренд на удаленную работу в ІТ. Кто-то остался работать в опустевшем офисе, кто-то уже мечтает вернуться туда поскорее, а кто-то принял новые правила игры и в итоге остался доволен.

Привет! Меня зовут Роман. Я Java-разработчик в компании SoftServe. Предлагаю вашему вниманию историю о том, как я встретил карантин, как организовал рабочее место и досуг. Статья не содержит секретных техник работы из дома или советов по борьбе с прокрастинацией и носит больше развлекательный характер. Поехали!

Intro

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

$ mvn test

------------------------

BUILD SUCCESS

------------------------

$ git commit

$ git push

Билд пайплайна чекну уже дома. В принципе из незаконченных дел остались только непрочитанное сообщение в Slack и недопитый латте. «Видели, как вирус лютует в Китае? Жесть просто!» — сообщение повисло на экране. «Что еще за вирус?» — подумал я. Из беглого осмотра новостей узнал, что в каком-то из городов Китая началась эпидемия вируса, который чем-то примечательнее остальных. Мало ли уже было разного рода эпидемий, терактов и катаклизмов, о которых я бы не знал, если бы изредка не интересовался сводками новостей. Пустой пластиковый стаканчик летит в мусорное ведро у стола, а ноутбук упаковывается в рюкзак. До текущего момента подобные происшествия мало влияли на мою жизнь и жизнь моих близких. С этими мыслями я закидываю рюкзак на плечо и иду к авто на парковку. Пора домой.

It’s coming

День за днем обсуждение вируса становится темой номер один. Каждый вечер, направляясь с работы домой, я слушаю выпуск новостей и надеюсь, что пандемию удастся локализовать в Китае. Но, к сожалению, данные не утешительные: вирус начали диагностировать далеко за пределами страны, включая США и Европу. Постепенно в разных странах вводятся жесткие ограничения на передвижение граждан, с чем мне бы очень не хотелось столкнуться в Украине. Шутки про посылки с AliExpress уже не кажутся такими смешными.

О том, что мой образ жизни в скором времени изменится, стало понятно, когда вирус обнаружили в соседней России и Республике Беларусь. В очередной раз прогревая двигатель на парковке, я слушаю выпуск новостей и узнаю о первом подтвержденном случае COVID-19 в Украине. В принципе этого следовало ожидать. Главное — не поддаваться панике.

Let’s get the lockdown started

«Без паники», — сказал я себе и затарился продуктами на две недели, предварительно заправив бензобак до отказа. По улицам уже ездят патрули, оповещая всех через рупор об опасности нахождения в общественных местах. На корпоративную почту приходят письма с рекомендациями по возможности работать из дома, а очереди за антисептиками в аптеках и изрядно опустевшие полки супермаркетов только подкрепляют во мне это желание. Более того, стало очевидно, что скоро государство введет повсеместный карантин. Не вижу смысла дожидаться официального распоряжения властей, поэтому принимаю решение работать удаленно уже сейчас. Я считаю, что нам, IT-шникам, крупно повезло! У нас есть возможность продолжать работать в условиях карантина, в то время как представители множества других профессий в лучшем случае понесут убытки, а многие просто потеряют работу. Остается пустяк — работать так же продуктивно, как и до этого в офисе.

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

— Алло! Привет! Слышал, что творится?

— Привет! Да, жесть полная.

— Я тут подумал, может, нам лучше поработать какое-то время из дома?

— Да, норм идея. Я тоже про это поду...

— Из твоего дома.

— Э-э-э... Ну окей.

У брата, кстати, «дано» аналогичное моему, за исключением двух последних пунктов, так что план должен сработать.

Day 0

Понедельник. Я собираюсь на работу. Ничего необычного, кроме двух вещей: в «офис» теперь в другую сторону и он в два раза ближе ко мне. А также в рюкзак теперь нужно взять чуток побольше девайсов. Начнем с рюкзака — это OGIO Renegade RSS 15. Офигенный рюкзак для гиков, которые любят таскать с собой все барахло.

Из особенностей рюкзака выделю защищенный отдел под ноутбук, куда отлично влазит корпоративный Macbook Pro 15 2015 года (будь он неладен). Мой любимый ThinkPad X1 Carbon 6, соответственно, переезжает в соседнее большое отделение, куда, забегая наперед скажу, влазит еще внешний монитор на 15 дюймов вместе с наушниками. Остальное, а это мышь Logitech MX Master 3, коврик под нее, любимый планшет Nexus 7, внешний SSD и всякая другая мелочь, распихивается по остальным кармашкам. В итоге рюкзак выглядит вот так.

Весит все это добро под 12 кг, что в свое время не мешало мне ходить на работу пешком 5 км туда и обратно. Но теперь, к сожалению, такие прогулки отменяются. Кстати, чтобы обезопасить содержимое рюкзака, использую два карабина, которые лочат все карманы, кроме двух боковых, куда ложу не самые ценные вещи. В общем, теперь что-то вытащить из рюкзака постороннему практически нереально. Bobby, выкуси!

Ах, да! Чуть не забыл! Мегаважная штука для питания всех девайсов — это удлинитель с USB-портами. Особенно в поездках этот девайс № 1 после паспорта.

And the last, but not the least it’s подставка под ноутбук. Спина тебе скажет спасибо.

По пути заезжаю в супермаркет и затариваюсь мыслетопливом. Благо это не средство первой необходимости, так что в наличии.

Спустя 15 минут я на месте. После разгрузки всех девайсов получается следующее рабочее место. В качестве бонуса выступает 43-дюймовый 4к телек, к которому у меня, конечно же, есть с собой кабель.

Наушники на голову. Музыку чуть громче. Command + Spacebar. Intellij IDEA. Enter. Погнали работать.

Day 4

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

А тем временем ситуация ухудшается. В Украину возвращаются граждане, которые были на заработках в Европе, в том числе из Италии, где ситуация, судя по новостям, катастрофическая. В Украине фиксируются новые случаи заражения. В компании принимают решение закрыть офисы (для посещения). В аптеках километровые очереди. Антисептики стоят бешеных денег. Маски вообще фиг найдешь. Я не склонен к панике, но неосведомленность в реальных масштабах трагедии плюс текущее состояние медицины в стране особо надежды не вселяют. Буду-ка лучше работать из дома. Колонна военных грузовиков, которая встретилась мне по дороге домой, почему-то усилила это желание.

Work from home

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

Кстати, по поводу наушников, если у вас в квартире нет отдельного рабочего кабинета, то наушники — это последняя вещь, на которой следует экономить (разумеется, после кресла). Сначала у меня были полноразмерные KOSS UR-20. Активного шумоподавления нет, тем не менее под фоновую музыку в них значительно легче концентрироваться на работе. Единственное, чего не хватает, — это микрофона (для митингов приходится перестегиваться на гарнитуру) и басов. С обеими проблемами отлично справились новые Corsair HS50 Carbon.

Кресло — Tesoro Zone Balance. Это как раз тот случай, когда думать нужно, простите, ж...пой. Выглядит офигенно! В разы комфортнее среднестатистического офисного кресла. Но на порядок менее комфортно специализированного кресла для работы за компьютером. Я сейчас даже не намекаю про Herman Miller. Жаль, не помню название, но неброские кресла из моего офиса, на удивление, оказались более комфортными для длительной работы.

Было время, когда в универе я программировал на 9-дюймовомнетбуке Acer Aspire One и мне хватало. Теперь же мне подавай внешний монитор, а лучше два. Первый — это 29″ LG 29UC88-B. Несмотря на незначительные засветы по углам (к которым я был готов на момент покупки), монитор просто отличный! Соотношение сторон 21:9 позволяет без проблем размещать рядом сразу два окна браузера. Также на нем удобно резолвить merge-конфликты. Чуть позже я докупил себе портативный 15.6″ MSI Optix MAG161V. Дома на него вывожу Slack и консоль. В поездках использую как второй монитор к ноуту.

Переходим к столу. Тут все просто — обычный деревянный стол местного производства (©купуй українське). Кстати, это единственный инстанс мебели в квартире, который я собирал собственноручно. Но, как видно по фотографии, со временем места на нем стало катастрофически не хватать, поэтому был заказан новый экземпляр (но об этом чуть позже).

Life-work balance

Есть у нас в компании тестировщик (Женя, привет!), который удаленно работает с самого начала проекта, задолго до карантина. Примерно спустя месяц карантина он спросил: «Пацаны, а вы заметили, что стали больше работать?». Я это заметил, но, как оказалось, не осознал. Заметил, потому что уже давно практикую технику Pomodoro и знаю, что обычная норма это 10 помидорок в день. Если удалось «насобирать» 12, это уже считается продуктивным днем. Все, что больше — переработки. Так вот первое время этот показатель ниже 11-12 непадал. Нередко улетал за 14.

Проблема в том, что клиент из Техаса и когда у нас наступает вечер, там рабочий день только начинается. Соответственно, Slack кипит, письма в почту летят, а поскольку ноутбук стоит открытый на столе, то ничего не мешает быстренько ответить. Сначала вникнуть в суть вопроса и ответить. Поправить документацию и ответить. Оп, уже 22:00, карапуз с любимой ушли спать. Хорошая возможность закрыть задание в спокойной обстановке. Command + Spacebar. Intellij IDEA. Enter. Ну вы поняли.

Скоро стало понятно, что в таком режиме можно быстро сгореть. Тут я посмотрел в другой угол комнаты, где давно пылится моя беговая дорожка. Более полезного девайса для самоизоляции найти сложно.

Самое смешное, что буквально за пару недель до повсеместного карантина я, ничего не подозревая, реально собирался ее продать. Теперь у меня каждое утро небольшая пробежка или же пешая прогулка. Очень в тему Pluralsight открыл бесплатно доступ ко всем ресурсам на месяц. Во время прогулки на дорожке я ставлю перед собой планшет и смотрю лекции. После этого идут упражнения с гантелями, отжимания и пресс. Весь комплекс плюс душ занимают минут 40-50.Это то время, которое я тратил, чтобы добраться до работы.

После ОФП (общая физическая подготовка) наступает один из моих любимых моментов.

До ежедневного статус-митинга остается минут 15, за которые я успеваю просмотреть новости под баночку мыслетоплива и плиточку шоколада.

Зарядка с утра — это конечно хорошо, но в течение дня также нужно делать перерывы. Так как все эти «пойдем попьем кофе/зарубимся в Mortal Kombat» больше недоступны, встал вопрос об «импортозамещении». Была мысль уделять каждую свободную минуту самообразованию, но здравый смысл взял верх, и я решил осилить давно купленную серию комиксов про Бэтмена.

Спать я ложусь намного позже, чем мой мелкий и любимая. Бывает, трачу это время на чтение книг и просмотр лекций, но значительно чаще просто захожу на YouTube подеградировать. Со временем это надоело и я заказал себе Xbox One X. Так сказать, решил вспомнить молодость. Думаю, тут нужно объясниться, постараюсь быть краток: я вертел эксклюзивы от Sony :) Покупал в основном ради двух игр: DOOM 2016 и DOOM Eternal, которые прошел с большим удовольствием. Признаюсь, был не прав. Оказывается, в шутеры можно играть на геймпаде, хотя половину первого DOOM у меня горело знатно, пока не привык к управлению. Зато теперь какой кайф после рабочего дня откинуться в кресле с геймпадом и погонять демонов.

Home office upgrade

А тем временем ко мне доехал новый стол, опять же отечественного производителя (©купуй українське). На вид он казался проще моего текущего, и я решил собрать стол сам. Но, когда открыл пакет с метизами, понял, что мне легче будет перейти с Java на Brainfuck, чем собрать его до того, как выгорит Солнце. Я вызвал сборщика мебели и спустя два часа и 600 гривен уже раскладывал свои девайсы на новый стол.

Я очень доволен своим новым рабочим местом. Широкий стол, на который наконец-то поместились все мои ноутбуки и мониторы, а также удобное кресло уже сами по себе располагают к работе. Оба ноутбука, корпоративный Macbook Pro 15 и мой персональный Thinkpad X1 Carbon, подключены к широкоформатному монитору. В зависимости от того, на каком из них работаю, переключаю на монике источник сигнала. Вечером же переключаю вход на коробокс, чуток поднимаю монитор, наклоняю его вниз, беру геймпад и откидываюсь в кресле. Кайф консоли как раз в этом — я играю в расслабленном положении, а не в «рабочем».

Outcomes

Вот уже больше 5 месяцев прошло с начала карантина. Что можно сказать? Несмотря на все проблемы, которые принесла эпидемия, я вижу два несомненных плюса. Первый — оказалось, что программисты вполне могут работать и взаимодействовать друг с другом удаленно. Второй — компании (вынужденно, конечно) понимают то же самое. Судя по всему, удаленная работа в ІТ останется трендом минимум до 2021 года.

Скучаю ли я за офисом? Не особо. Скажу так, в том, чтобы ходить в офис (пешком в хорошую погоду), по пути брать себе чашечку кофе, обсуждать что-то с коллегами на кухне, есть смысл. Это приносит удовольствие и, вероятно, помогает многим разграничивать рабочее время от досуга. Но с другой стороны, на дорогу туда и обратно, особенно в час пик, уходит целый час, а иногда и больше. Теперь же я это время трачу на ОФП или онлайн-курсы.

Отвлекает ли от работы домашняя обстановка? Буду честен — да, иногда отвлекает. Но если быть уже честным до конца, то скажу, что шум в опенспейсе, часто дает фору мультикам на заднем плане и капризам моего малого. Более того, спустя пару недель работы из дома я, можно сказать, вошел в режим. Утром уделяю время ребенку, потом ОФП. Дальше мелкий идет на прогулку с мамой, и у меня есть пару часов на продуктивную работу. После прогулки шкет получает свою порцию молока и тут же идет на обеденный сон. Это еще три часа тишины. Потом примерно полтора часа он играется дома. В это время я обедаю и уделяю ему внимание. Потом снова прогулка на пару часов, а для меня время поработать. Да, в карантин мы выходим на прогулки, соблюдая все меры предосторожности. Вечером же я провожу время с семьей, и, когда мелкий идет спать, у меня остается пару часов до полуночи на досуг. Так и живем.

Кстати, по поводу митингов. К сожалению, у меня пока нет своей отдельной комнаты, где бы я мог закрыться на целый рабочий день, поэтому иногда беру ноут, наушники, внешний монитор и иду в спальню. Закрываю дверь, ставлю все это на комод и стоя участвую в митингах. Думаю, иногда полезно часик поработать стоя.

Post scriptum

Надеюсь, что в скором времени эта эпидемия закончится и люди вернутся к прежней жизни. А также, что после этого тренд на удаленную работу в ІТ сохранится и дальше. А тебе, мой дорогой читатель, я желаю быть позитивно настроенным, ладить со своей семьей и близкими и с пользой проводить время, которое ты больше не тратишь на commute.

Приветствую всех, кто решился прочитать статью. Речь пойдет о проблеме профессионального выгорания, которое рано или поздно настигает большинство людей и даже в такой динамичной сфере, как ІТ. Точнее, поговорим о способах ее решения, испытанных на собственном опыте.

Я работаю в IT то ли шесть, то ли семь лет (после определенного срока уже теряешь счет), начинал фрилансером, на сегодня имею опыт работы в трех компаниях. Еще раньше преподавал боевые искусства, а потом получил и педагогическое образование. Умело совмещать профессии оказалось невозможно, и программирование все-таки поглотило меня полностью, но к преподаванию я все-таки вернулся. В частности, об этом расскажу в статье.

Этот материал для опытных разработчиков, которые вступили в сложный период прокрастинации, и начинающих специалистов, которых эта проблема ждет впереди.

Заголовок вдохновлен романом «Облачный атлас» Дэвида Митчелла. Как говорится, не все поймут, но многие вспомнят (а кто не вспомнит, очень советую ознакомиться).

Конечно, с описанной проблемой я временами сталкиваюсь до сих пор, но теперь у меня есть несколько проверенных способов (тактических и стратегических), которые помогают встретить «прокрастинационный синдром» с шашкой наголо.

Иллюстрация Ульяны Патоки

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

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

Однажды задумавшись над этим высказыванием, я стал делить разработчиков, встречавшихся на моем пути, на два типа. К первому относил людей, которые смирились с тем, что движутся медленнее окружающего их мира технологий. Они предпочитают идти следом по путям, оставаясь в колее, но не замечают, что она уже давно поросла травой. Собственное нежелание напрягаться эти разработчики оправдывают тем, что выучить все на свете в любом случае невозможно.

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

Однако программисты обоих типов подвержены профессиональному выгоранию. Первые начинают отставать от коллег и рискуют застрять в поддержке поросшего бородой проекта. В худшем случае еще и в захудалой конторе без перспективы роста. Проблемой вторых может стать отсутствие достойных их обширных знаний задач, поскольку даже крупные компании не всегда поставляют их регулярно. Это способно привести программиста к мысли о бесполезности собственных трудов и перевести в режим «вялого тления».

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

Признаки выгорания

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

Основы языка начинают забываться. В какой-то момент мне оказалось гораздо сложнее прежнего ответить на базовые вопросы, значение которых было очевидно даже на старте карьеры. Более того, именно эти знания составляли весомую часть багажа в моей черепной коробке. Самый страшный момент, когда даже нагоняй от зеленого специалиста, полученный в проходном споре за чашкой кофе, не мотивирует повторить азы, чтобы проверить и усвоить новую информацию.

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

Что же делать

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

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

Делитесь. Печеньем приятно угостить хороших людей, особенно если съесть весь запас одному все равно не получается. Следующая остановка — выбор интересной темы для написания статьи. Допустим, вы хотели реализовать микросервис, но до этого никак не доходили руки, а может, в голове крутилась идея крутой анимации, которая так и осталась фантазией. Прекрасный челлендж — попытаться пошагово, понятным языком изложить, как достичь результата, который виделся вам в воображении. Это поможет слегка улучшить карму, а некоторое количество потенциальных лайков даст возможность почувствовать себя немного творцом. Такое ощущение безусловно придаст сил изучить что-нибудь новое. Я, например, взял за правило время от времени шерстить сайты (скажем, dribbble.comили behance.net), на которых дизайнеры выкладывают интересные, а иногда совершенно непостижимые решения. Там выбираю то, что больше всего понравилось, и реализовываю идею для себя. Такая практика особенно поможет, если вы займетесь менторством, начнете преподавать или выступать с докладами.

Менторство — это про «научить другого тому, что умеете или умели, или чему хотели бы научиться сами; помочь программисту на пути становления». Человек, которому вы поможете, будет счастлив видеть своим учителем успешного специалиста. Но, что немаловажно, его вопросы заставят вас раскопать былые знания, а может, вдохновят сотворить что-то новое.

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

Помимо пользы самого процесса подготовки, выступление обещает интересный опыт и, возможно, как в моем случае, незабываемые воспоминания. Помню, как выступал в Виннице на одной из конференций, все вроде бы шло хорошо, даже слишком. В моем случае «слишком хорошо» значит, что что-то вот-вот случится. Довольный своим выступлением я поблагодарил всех за внимание и прямо со сцены отправился звонить домой. Первым делом набрал маму, как всегда после выступлений. И долго недоумевал, почему люди в зале машут мне руками и показывают на уши. Потом понял, что забыл снять микрофон, так что наш разговор слышали все. Хорошо, что мои впечатления и правда были самыми лучшими: все в этом убедились, а я получил возможность лишний раз похвалить аудиторию и организаторов. А если бы мне хотелось срочно поделиться возмущением? Ведь в принципе спектр возможных впечатлений от конференции необъятен!

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

Я уже два года преподаю в местной школе программирования и хочу сказать, редко слышал, чтобы весь курс проходил у кого-то из молодых преподавателей без сучка, без задоринки. Я уже говорил, что основы забываются легко и быстро, а от учеников часто слышишь вопрос формата «а что будет, если...» с совершенно неожиданным продолжением. Не раз я возвращался домой в состоянии, близком к депрессии, после того как, стоя у доски перед аудиторией из шестнадцати человек, с уверенным видом отвечал абсолютно мимо. Такое иногда и сейчас происходит, правда, я научился проще относиться к подобным ситуациям (ведь невозможно знать все), а это еще один жирный плюс!

Но главное, что осознание собственной оплошности перед людьми, которые пришли учиться у вас, заставит повторно разобрать тему, прежде чем вернуться к группе. Мои товарищи по преподавательскому цеху могли не сталкиваться с подобными вопросами, но все как один знакомы с проблемой организации обучения для людей разного уровня подготовки. Это подкидывало угля в печь их творческой активности и в результате помогало в работе. Ну а когда большая часть ваших студентов устроиться на работу и скажет спасибо — вас ждет повышение так называемого ЧСВ! Это совсем неплохо, останется только держать его под контролем.

В конечном счете вам надоест вести занятия по накатанной и вы займетесь подготовкой нового материала, чтобы не дать скучать ни студентам, ни самому себе. Или можете просто вступать в дискуссии на интересные темы. В конце концов именно в споре рождается истина, если умеете признать свою неправоту.

Доклады на конференциях сильно отличаются от менторства или преподавания. Такие сессионные выступления ограничены во времени и дают еще больше свободы в выборе темы. При этом они также требуют постоянного взаимодействия с аудиторией и поэтому отлично подойдут как подготовка к преподавательской деятельности. Кроме того, для крупных конференций недостаточно желания выступить, скорее всего, придется доказать, что вы этого достойны, представив доклад организаторам. Зато, когда набьете руку, вас начнут приглашать персонально. Здесь становится вдвое интереснее!

Вместо заключения

Делиться знаниями, на мой взгляд, — один из самых надежных способов избежать выгорания. Мало что мотивирует так, как обратная связь от людей, которым вы помогли узнать новое: студентов, практикантов, слушателей курсов или зрительного зала. При этом менторство, выступление на конференциях, ведение занятий в вузе или на курсах — разные направления. Если один из них не подошёл, имеет смысл попробовать силы в другом. И конечно, не забывайте переключаться: ни один проект не должен съедать ваше время полностью. Читайте, смотрите кино, играйте: компьютер и лампа на столе нужны не только для работы. Не забывайте регулярно проветривать комнату и гулять, смотрите по сторонам и не стесняйтесь иногда потешить самолюбие!

В нашей профессии важно не упустить момент, когда угольки готовы погаснуть, и проявить настойчивость, бросая вызов самому себе. Жесткие рамки не позволят сделать шаг навстречу прокрастинации. И куда приятнее выставить их для себя самостоятельно.

[Дмитрий Овчаренко — CEO & Founder в Alcor, вице-президент по юридическим и финансовым вопросам Ассоциации IT Ukraine, 15+ лет в оперативном управлении ІТ-бизнесом, помог десяткам иностранных технологических компаний открыть R&D-офис в Украине]

Что, собственно, следует знать и на что обратить внимание, чтобы релокация иностранцев прошла без проблем? Сегодня этот вопрос стоит как никогда остро. Все больше украинских и иностранных IТ-компаний нуждаются в перемещении своих работников на территорию Украины.

Именно поэтому мы подготовили небольшой гайд о том, как правильно организовать процесс и что в первую очередь необходимо сделать иностранным специалистам.

События в Беларуси уже который день приковывают внимание как украинского, так и мирового сообщества, что с беспокойством наблюдает за насильственным подавлением протестов.

Украинское ІТ не стало исключением. Резонанс вызвало открытое письмоот ІТ-сообщества Беларуси относительно возможного выхода из страны в случае продолжения неблагоприятной для бизнеса ситуации и отключения интернета. НекоторыеІТ-компании заявляюто готовности переехать в Украину, если массовые аресты будут продолжаться. И Украина действительно может стать удачной локацией для белорусских специалистов, чтобы вести свою деятельность без помех.

Почему? Если не вспоминать культурную и географическую близость, а еще развитую инфраструктуру, то можно выделить несколько основных преимуществ такого решения:

• Упрощенный въезд.Чтобы пересечь границу с Украиной, белорусам не нужна виза. Граждане Беларуси могут находиться на территории Украины до 90 дней без особых разрешений и за это время оформить документы для дальнейшего пребывания в стране (детальнее об этом далее).
• Простая легализация. Процесс легализации иностранцев в Украине несложный, особенно если работать с местными экспертами по иммиграции. Кроме того, Министерство цифровой трансформации создало квоты для трудоустройства иностранцев.
• Благоприятные условия для ІТ-бизнеса. В сфере ІТ Украина достаточно свободна в плане регулирования. На рынке работает много компаний с различными бизнес-моделями.

Со своей стороны украинское правительствои бизнес уже заявили о готовности помочь белорусским предпринимателям организовать бесперебойную работу компаний в Украине. Коворкинг, юридические фирмы и собственно ІТ-компании предлагают особые условия, а Ассоциация ІТ Украины готова оказать юридическую поддержку белорусским специалистам.

Что нужно для легализации белорусов в Украине?

Важно отметить, что белорусы могут безвизово пересекать границу с Украиной. Но для того, чтобы иметь возможность находиться на территории Украины более 90 дней, иностранцам необходимо пройти процедуру легализации. Существует несколько ее вариантов.

Вариант 1. Легализация через трудоустройство

В таком случае белорусы могут получить право на работу в Украине на срок от 3 месяцев до 3 лет, а также вид на жительство. Такой процесс начинается с получения разрешения на трудоустройство. Этот этап инициирует компания, на которую будет работать иностранец. Важно, что личное присутствие специалиста необязательно. Необходимы лишь:

1. Скан-копия паспорта иностранца.
2. Цифровое фото паспортного формата.
3. Трудовой договор с указанием уровня заработной платы, должность, условия труда и тому подобное.

После получения разрешения белорусы беспрепятственно могут приехать в Украину и продолжить процедуру легализации.

Следующие шаги — получение карты налогоплательщика и вида на жительство. Эти две процедуры стоит начинать одновременно для ускорения процесса. Для карты налогоплательщика следует подать перевод паспорта, штамп последнего въезда и заполненную анкету. Это можно сделать лично или через представителя.

Что касается вида на жительство, то для его изготовления необходимо личное присутствие иностранца при подаче документов и выдачи готового документа (связано с биометрическими данными). Документы, нужные на этом этапе:

1. Паспорт и нотариально заверенный перевод на украинский язык.
2. Оригинал разрешения на трудоустройство.
3. Договор медицинского страхования.
4. Письмо-обязательство от компании-работодателя.

Далее иностранцу следует зарегистрировать место проживания в течение 30 дней с момента получения вида. После этого происходит официальное оформление трудоустройства и заключения трудового договора между иностранцем и компанией.

Вариант 2. Работать и заниматься предпринимательской деятельностью по упрощенной системе налогообложения (уплата 5% налога с дохода)

Такой подход позволяет оформить иностранца как частное лицо-предпринимателя и, кроме основного трудоустройства, получать прибыль от предпринимательской деятельности, платить только 5% налога на доход + примерно 32 евро в месяц как социальный взнос.

В таком случае к предыдущему перечню действий добавляется еще один пункт — регистрация ФОП и постановка на учет плательщиком единого налога. Для этого необходимо подать паспорт, вид на жительство в Украине, документ о присвоении номера налогоплательщика и заявление на регистрацию в качестве ФОП.

После получения свидетельства о регистрации ЧП иностранец может сотрудничать с любой компанией в Украине на правах частного предпринимателя и платить минимальный налог.

Квоты для иностранных ІТ-специалистов

А еще в Украине действуют специальные условия для иностранных специалистов, которые сотрудничают с ІТ-компаниями. По инициативе Министерства цифровой трансформации были созданы квоты для иммиграции 5000 иностранных специалистов и их трудоустройства в ІТ-компаниях. В рамках этих квот программисты получат вид на постоянное место жительства в Украине сроком на 10 лет с возможностью регистрации частным предпринимателем и без необходимости ежегодно обновлять разрешение на трудоустройство.

В таком случае иностранцу необходимо получить разрешение на иммиграцию, подав к рассмотрению документы в Украине или в посольство Украины в своей стране. Затем инициировать получение вида на жительство, а после этого зарегистрировать место проживания. Тогда оформлять ФОП и сотрудничать с компаниями в Украине в роли подрядчика.

Если двигаться по такому сценарию, стоит понимать, что по законодательству принятие решения о разрешении на иммиграцию не должно длиться более 1 года.

И еще один важный момент — эта квота действует для специалистов по исключительным перечнем профессий в сфере ІТи требует подтверждения соответствия требованиям к работникам (диплом, сертификат, 5 лет руководящего опыта для менеджера, 7 лет — для программиста).

Организация бизнеса в Украине: дополнительные вызовы

Но, говоря о нынешнем кризисе в Беларуси, следует понимать, что просто перевести людей в Украину будет недостаточно для продолжения функционирования ІТ-компаний. В условиях неопределенности в стране кажется, что белорусскому ІТ-бизнесу может понадобиться плацдарм для деятельности на длительное время. А значит, его переезд в Украину будет охватывать также многие другие аспекты, а именно:

• обеспечение юридической прозрачности и комплаенс деятельности компании с украинскими правовыми нормами. Это значит, что юристам компании нужно будет оперативно разобраться во всех подводных камнях украинского законодательства;
• выбор эффективной бизнес-модели, которая будет достаточно гибкой в ​​условиях неопределенной продолжительности пребывания компаний в Украине, чтобы не провоцировать лишние вопросы от контролирующих органов;
• необходимость открытия счетов в местных банках для сотрудников и налаживание процесса выплаты заработной платы, если ситуация в Беларуси будет развиваться по неблагоприятному сценарию;
• поиск офиса/коворкинга для размещения команды (хотя в условиях карантина и удаленной работы порой можно обойтись и без него). Ведь может быть трудно найти вариант, который бы удовлетворил и в плане комфорта, и с финансовой стороны. И хотя украинские ІТ-компании готовы предоставить своим белорусским коллегам рабочие места, их количество ограничено. Также не стоит забывать о настройке инфраструктуры, включающей перевозки или закупку нового оборудования и обустройства рабочих мест.

Конечно, мы все наблюдаем за событиями в Беларуси и желаем, чтобы конфликт был решен мирным путем, а право народа на свободное волеизъявление было соблюдено. Однако Украина может стать хорошей альтернативой, чтобы избежать простоя компаний в Беларуси из-за отсутствия интернета и угрозы жизни сотрудников. Радует, что украинское ІТ-сообщество готово идти навстречу и помогать белорусскому ІТ-бизнесу продолжать свою деятельность.

Также читайте, что говорят белорусские ІТ-компании о ситуации в стране.

[Дмитрий Вартанян, CFO, Co-Founder сервисной ІТ-компании Sigma Software, Co-Founder инвестиционного фонда Inspirium Laboratories, 20+ лет опыта работы в ІТ в области права и финансов. Статья написана в соавторстве с Валерием Красовским, CEO, Co-Founder сервисной ІТ-компании Sigma Software, Co-Founder инвестиционного фонда Inspirium Laboratories, 20+ лет опыта в ІТ]

В Раде зарегистрированы два законопроекта: № 3933и альтернативный ему № 3933-1 (плюс связанный с ним ЗП № 3979). Согласно пояснительным запискам, документы направлены на развитие индустрии информационных технологий и повышение конкурентоспособности. Мы попытались сформулировать в одной статье, что предлагают авторы законопроектов и что действительно нужно ІТ-индустрии для развития, а также — как это совместить.

Основа обеих законотворческих инициатив — снижение ставки налога на оплату труда для ІТ-компаний с текущих 41,5% (18 НДФЛ + 22 ЕСВ +1,5% военный сбор) до более приемлемых цифр: 5% НДФЛ + 5% ЕСВ.

В отрыве от контекста оба закона сильно уменьшают налогообложение оплаты труда для ІТ-компаний по отношению к общей системе. Но реальность такова, что большая часть отрасли работает не по трудовым, а на едином налоге (ЕН) с оплатой 5% + ЕСВ с 1мзп, что в среднем составляет 6,5%. И в этом смысле оба законопроекта, хотя и преследуют благую цель, по факту ухудшают два существенных условия работы в ІТ:

1. Увеличивают налоги с 6,5% до 10%+ (на самом деле, реальное усредненное налоговое увеличение в обоих законопроектах сильно выше декларируемых 10% из-за «деталей» реализации, смотрим таблицу ниже).
2. Предполагают замену свободных контрактных отношений между ФОП и компанией, на КЗоТ 1971 года выпуска. В законопроекте № 3933-1 сказано о контрактной форме взаимоотношений, но пока что непонятно, как именно это будет реализовано, так как трудовые взаимоотношения регулируются КЗоТ, который еще не изменен, и неизвестно, будет ли изменен и как именно.

Поскольку последние 20 лет ІТ-отрасль развивалась благодаря этим двум факторам, то их реформировать рискованно для бизнеса. Достигнутая такой реформой легализация тоже может быть сомнительной: ІТ работает де-факто не по правилам КЗоТ, а значит, одни нарушения заменяются другими.

Цифры по налогам

Ограничение на работу с ФОП

Прямых ограничений на работу с ФОП на ЕН в законопроектах нет, но они вытекают из конструкции законов.

В ЗП № 3933 расходы на оплату труда должны составлять 50% от расходов. Остальные 50% могут в принципе идти на любые расходы, в том числе на ФОП. Но надо понимать, что у ІТ-компаний есть еще расходы на аренду, оборудование и так далее. Поэтому иметь больше 20-30%контрактов с ФОП вряд ли получится.

Установление квоты в 50% на работы по трудовым может приводить к странным ситуациям, когда кандидат на собеседовании заявляет, что хочет работать с компанией через ФОП-контракт, а у компании, например, закончился лимит и она может предложить только трудовые взаимоотношения. Возникает ограничение, которое довольно легко обходится существующими схемами оплаты, но тогда мы не приходим к цели законопроекта: прозрачности бизнеса.

В № 3933-1 все намного жестче, здесь работа с ФОП блокируется на двух уровнях:

1. 70% затрат ІТ-компании должно приходиться на заработную плату.
2. Любая оплата на ФЛП на едином налоге автоматически приравнивается к получению прибыли и облагается налогом по ставке 18% (ст. 141.9.2.13). Это помимо самого ЕН, то есть 23% итого.

Здесь интересна логика расчета налоговых последствий, которая стоит за этим подходом: 1) поскольку не все специальности в ІТ-компании могут быть ФОПами, значит, 2) порядка 10% должны быть на трудовых уже сейчас с оплатой 41,5% налогов, тогда 3) при уменьшении для таких сотрудников налогов с 41,5% до 10% можно скомпенсировать 4) увеличение налогов при переходе ФОПов с 6,5% налогов на 10% на трудовых.

Данный ход рассуждений очень спорный, но и сам законопроект № 3933-1 его перечеркивает в статье 14.1.280 к Налоговому кодексу, где определяет работников ІТ-индустрии как лиц, которые «безпосередньо задіяні у видах економічної діяльності в індустрії інформаційних технологій, за переліком, визначеним» Минцифрой. То есть 10% налогов будет распространяться не на всех сотрудников ІТ-компаний, а на тех, кого определит Минцифра.

Даже если закрыть глаза на нюансы и признать, что 10% налогов на трудовые отношения для ІТ-компаний могло быть благом, в законопроектах есть ряд однозначно вредных условий применения этих льгот:

• реестр ІТ-индустрии;
• создание нового контролирующего/уполномоченного органа, который будет регулировать ІТ-индустрию;
• навязывание применения КЗоТ, который для ІТ в принципе не применим без его же нарушения.

Реестр ІТ-индустрии

На первый взгляд кажется логичным, что для использования специального режима налогообложения нужно пройти определенные процедуры и зарегистрировать этот статус в налоговой. С тем же единым налогом именно так и происходит. Оба законопроекта предполагают, что налоговая будет вести некоторый реестр ІТ-компаний. Но, чтобы туда попасть, возникают дополнительные органы регуляции.

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

В законопроекте № 3933-1 решение о регистрации ІТ-компании как субъекта ІТ-индустрии принимает уполномоченный орган (статья 6 ЗП 3933–1)с полным перечнем полномочий: регистрация, отказ в регистрации и исключение ІТ-компании из реестра. При этом тот же самый уполномоченный орган (здесь это четко Минцифры, согласно ЗП № 3979) формулирует требования к форме и содержанию документов для регистрации. Он может в любой момент потребовать любые документы, таким образом осуществлять ничем не ограниченные проверки субъектов ІТ.

На практике, когда один и тот же орган сам формулирует требования и сам же их проверяет, возникают хорошо известные регуляционные последствия. С точки зрения законотворчества, это нарушает базовую парадигму разделения законодательной и исполнительной властей. Да и в целом непонятно, зачем вводить какую-либо регуляцию отрасли, которая, по словам тех же авторов, развивается с темпом 30% в год.

КЗоТ vs ФОП

Проблема КЗоТ в том, что все его нормы являются императивными, то есть не могут быть изменены в контракте по соглашению сторон. И даже само это правило нельзя изменить, поскольку базовая ценность КЗоТ в защите трудящихся от злоупотреблений владельцами средств производства своей властью, которая может быть навязана сотрудникам через контракты. В Украине очень развит социалистический популизм, поэтому изменить КЗоТ практически нереально, все, кто за это берется, резко теряют электорат.

Полный перечень проблемы при переходе на КЗоТ до конца не известен, но вот то, что точно не подойдет IТ:

• Удаленная работа по КЗоТ не предполагается.
• Длительные командировки невозможны, а для беременных невозможны в принципе.
• Изменение зарплаты с курсом доллара еще как-то можно сделать в сторону увеличения, но уменьшить уже не получится.
• Оформление бонусов/овертаймов сильно усложняется.
• Есть нормы командировочных расходов, установленных государством.
• Очень бюрократические отчеты по расходам, больничным, командировкам. Все эти печати, штампы, справки и так далее.
• Нарушения проверяются не дружественным бухгалтером, а налоговой и Держпрацi (Державна служба України з питань праці).
• Увольнения и отпуска строго в соответствии с КЗоТ, никаких проектных нужд и пожеланий заказчика.

Авторами законопроекта № 3933-1 декларируется его опциональность, то есть можно оставаться и на текущей схеме работы. Но тогда хотелось бы видеть в таком законопроекте четкую легализацию работы с ФОП на ЕН, чтобы обе модели были полностью легальными. Тогда бы он полностью соответствовал заявленным в нем целям, а это стимулирование развития ІТ.

Миф о том, что как только мы перейдем со схемы «ФОП — компания» на схему «сотрудник — компания», то это чем-то поможет

Часто говорят, что это поможет компаниям с IPO. Но небольшим и средним компаниям, которых большинство, это не нужно. А для крупных это не проблема. Примеры:

• EPAM с отличной капитализацией и огромным офисом в Украине отлично находится на бирже.
• Luxoft.
• Amazon купил Ring с большим офисом в Украине.
• недавно компания BigCommerce с программистами в Украине вышла на биржу, и это не вызвало проблем у юристов NASDAQ.

Наша материнская компания была на бирже, и контракты с ФОП в Украине не вызывали проблем. Я бы доверял мнению юристов NASDAQ. Никому не мешает схема взаимодействия ФОП — компания и не влияет на капитализацию.

Есть мнение, что венчурные фонды будут активней инвестировать. Тоже не выдерживает никакой критики. Наоборот, отсутствие КзОТ позволяет включить все необходимые ограничения, которые хотят инвесторы — NDA, NCA и так далее. А еще заключить особые условия по выходу из проекта, чтобы не рисковать потерей ключевых специалистов, что невозможно при любом трудовом кодексе.

Действительно, иногда необходимо рассказать и убедить клиента или инвестора, что взаимодействие «ФОП — компания» — это сложившаяся схема работы в Украине. Но у меня за 20 лет не было ни единого случая, когда это было шоустопером. Сейчас контрактные взаимоотношения и так называемая гиг-экономика, экономика работы с предпринимателями-фрилансерами, все больше набирает обороты в мире. Например, в Австралии примерно 50% предложений на рынке труда ІТ — для ІТ-контракторов, а не сотрудников. Украина в этом контексте первая в мире и может использовать это невероятно крутое конкурентное преимущество, чтобы стать действительно первой в мире инновационной и ІТ-страной.

Способствует ли законопроекты № 3933 и № 3933-1 развитию продуктового ІТ

Могут ли законопроекты помочь стимулировать увеличение доли продуктового бизнеса и/или стартапов по отношению к сервисному бизнесу в украинской ІТ-отрасли (или аутсорсингу и аутстаффингу)? Краткий ответ — нет. Повышением налогов (от текущей схемы «ФОП — компания» 6,5%) до предлагаемых 10-11,5%невозможно стимулировать людей создавать продуктовые компании.

В украинском обществе уже давно и постоянно наблюдается желание отдельных «экспертов» противопоставить сервисный бизнес и продуктовый. Они утверждают, что продуктовый более интересен, так как генерирует бОльшую прибыль на человека. И в целом это не лишено смысла, хотя и не является панацеей. Многие продуктовые компании работают на марже примерно такой же, как сервисные компании, ведь продукт необходимо развивать, поддерживать и бороться с конкурентами.

На самом деле в экономике не бывает «бизнеса, который нужен» и «бизнеса, который не нужен». Бизнес возникает, когда есть спрос, в свободной экономике. Не секрет, что есть компании с капитализацией в сотни миллионов долларов с мировыми именами, бизнес которых заключается в сервисе, аутсорсе и иногда даже только в аутстаффе. Хотим ли мы, чтобы в Украине было больше таких компаний как, например, Accenture? Конечно. Хотим ли мы, чтобы появлялись компании такие, как Microsoft? Конечно, хотим. Другое дело, что для этого не нужно каких-то сверх усилий, просто нужно не мешать экосистеме развиваться и не пытаться ее зарегулировать.

Логично, что украинское ІТ началось с сервисного бизнеса или аутсорса. И это не что-то плохое или заурядное, как это порой описывают. Когда обращаетесь к профессиональным юристам, вы аутсорсите юридическую составляющую своего бизнеса, когда к профессиональным бухгалтерами — экономическую составляющую, когда создаете ІТ-продукт — ее технологическую, а иногда частично и бизнес-часть — вы аутсорсите профессионалам из ІТ-бизнеса, которые создали уже много таких систем и точно лучше вас понимают, как эффективно это сделать. Аутсорсинг — это поручение определенного вида работ профессионалам. Украинское ІТ развивалось примерно так:

Аутстаффинг-> Аутсорсинг-> Сервис-> ІТ под ключ-> Создание продуктов в партнерстве и соинвестиции.

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

Почему же сервисный бизнес или ІТ-аутсорс дает возможности для развития продуктового бизнеса?

1. Благодаря сервисному бизнесу пришло понимание в принципе клиентоориентированного бизнеса, которого в СССР не было.
2. Пришло понимание западных рынков: как они работают, какие сервисы востребованы и как на них выйти, чтобы украинские стартапы стали успешными.
3. Начали понимать, где в бизнес-цепочке есть области, которые еще можно автоматизировать, сделать продукты.
4. Начали понимать, чем пользуются люди, какие сервисы хотят.

Большое количество украинских предпринимателей-стартаперов получили первый опыт в сервисном бизнесе и именно оттуда черпали идеи своих стартапов. Мы это знаем не понаслышке и активно ищем ребят, Senior-инженеров, которые работают в сервисном бизнесе и видят идею для продукта, но по разным причинам не могут ее реализовать. Через проект Sigma Software Labs даем возможность претворить их мечты в реальность. За счет чего же можем помочь это сделать?

1. Огромный опыт в разработке стартапов серийных ІТ-предпринимателей из США и Европы и прослеживание всего их пути от зарождения идеи до экзита.
2. Нетворк венчурных предпринимателей со всего земного шара и собственный инвестфонд, который уже вложил более 3 млн долларов в различные стартапы, из них около 2 млн в украинские.
3. Нетворк клиентов — крупных компаний, которые ищут инновации и открыты для новых решений и продуктов. Мы помогаем молодым предпринимателям с их ІТ-решениями выйти на наших клиентов в самых разных областях, это и automotive, healthcare, gambling, finance и многие другие.

Таким образом очевидно, что ІТ-экосистема, которая развивается, сама дает стимулы для своего же развития и появления различных компаний, в том числе продуктовых. Что же на самом деле нужно, чтобы стимулировать создание новых ІТ-продуктов?

1. Деньги.
2. Низкие налоги.
3. Менторство.
4. Выход на клиентов (в случае B2B).

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

1. Нулевые налоги для стартапа, скажем, на 3 года, причем и на оплату труда программистам. Ребята, которые идут работать в стартап из сервисной компании, рискуют — так дайте им лучше условия.
2. Возврат инвестиций сервисным компаниям, которые тратятся на R&D-разработки, в том числе на те, что проводятся совместно с техническими университетами. В некоторых странах существуют такие стимулы, когда идет компенсация R&D-затрат в разных объемах, до 25%.
3. Программа помощи украинским инвестфондам, как это было сделано в Израиле. Компенсация части вложений в случае неуспеха. В Израиле порядка 80% инвестиций государство обязалось компенсировать на старте поддержки стартап-движения. Вкладываешь 10 млн долларов и, если все стартапы были неуспешны, получаешь 8 млн долларов компенсации. В итоге государство ничего не потратило на эту программу, потому что не было полностью убыточных инвестфондов.

Что еще можно сделать, чтобы продуктовые компании инкорпорировались в Украине

Для чего это нужно государству? Разумеется, для того чтобы больше прибыли заходило в страну. Но сейчас и еще очень долго любой инвестор, особенно для начинающего стартапа, с большой долей вероятности выберет не Украину, даже не Литву, не Германию и даже не UK, а скорее всего, конкретно штат Delaware. Вот буквальная цитата из книги по инвестированию: корпоративные законы штата Delaware наиболее четко выписаны и бизнес-ориентированы, и большинство юристов в США — адепты работы с законодательством Delaware, а инвестиционные банкиры будут настаивать на том, что для выхода на IPO компания должна быть зарегистрирована именно там (Venture Deals Brad Feld).

Что нужно, чтобы это появилось у нас? Годы работы и построение доверия к судебной системе и в принципе к системе власти, чтобы не ждать каких-то изменений со стороны налогов и других регуляций. И плюс к этому реальные бесплатные деньги от государства для поддержки инвесторов, как в UK и Израиле. То есть буквальное денежное покрытие бизнес-рисков страны самим государством.

Самое простое и эффективное, что государство может сделать прямо сейчас, — мотивировать украинских айтишников больше денег оставлять в Украине, даже если они делают экзит американской компании в виде налогов, которые сейчас в разы ниже, чем в США, а также инвестиций в новые R&D. Заинтересовывать людей оставаться здесь жить стабильностью, хорошими дорогами, социальной ответственностью, нормальными больницами и, наконец, налоговой системой, которая позволяет зарабатывать больше, чем в других странах. Чтобы условия для получения денег для украинцев были лучше, чем в других странах, и тогда больше денег будет попадать в страну.

[Про автора: Альона Черненко-Диба — Operations Manager в Astound Commerce з 14-річнимдосвідом в ІТ — від джуніор тестувальниці до операційної менеджерки компанії. Її кредо як менеджерки: «Успіх вашої команди є досягненням команди, невдача команди є результатом вашого неефективного менеджменту»]

Кожен із нас хоча б раз запитував себе: кому я довіряю, а кому ні, й чому; як збільшити рівень довіри в команді/організації і чи потрібно це робити; чи варто довіряти комусь ще, окрім себе? І зустрічав людей, які впадають з одних крайнощів в інші: або ж нікому не можна довіряти (бо все одно всі зраджують чи обманюють), або ж всім треба довіряти без винятку.

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

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

Ілюстрації Аліни Самолюк

Поняття довіри

Спершу пропоную розібратись з терміном «довіра». Тлумачний словник української мови характеризує це як ставлення до кого-небудь, що виникає на основі віри в чиюсь правоту, чесність, щирість тощо. Стівен Кові («Швидкість довіри. Те, що змінює все», 2018) твердить, що довіра — це функція двох факторів: характеру і компетентності. Характер — це чесність, мотиви, наміри в стосунках з людьми. Компетентність охоплює здібності та навички, результати й професійні досягнення. Олена Яхонтова («Довіра в управління персоналом. Зарубіжний та вітчизняний досвід оцінки», 2004) вважає, що довіра є готовністю бути залежним від інших людей в ситуації невизначеності та очікуванні певної вигоди від цього.

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

Мені імпонує модель 5 хвиль довіри Стівена Кові, яка демонструє «хвильовий ефект» і взаємозалежну природу довіри з поширенням «зсередини назовні». Ця модель передбачає, що запускається певний механізм поширення довіри, змінюючи масштаб від меншого до більшого, у світі, де всі процеси взаємопов’язані, мають причинно-наслідковий зв’язок і зумовлюють одне одного. Отже, Стівен Кові виділяє 5 хвиль довіри:

1. Довіра на рівні особистості пов’язана з нашою впевненістю в собі, зі здатністю ставити цілі та досягати їх, виконувати зобов’язання й робити те, що говориш, вселяти довіру. Ключовий принцип — бути надійним і достойним довіри.
2. Довіра на рівні стосунків — про створення і збільшення довіри в стосунках з іншими. Ключовий принцип — послідовність поведінки.
3. Довіра на рівні організації пов’язана з тим, як лідери формують довіру загалом у компанії, а також у її командах та інших підрозділах. Ключовий принцип — узгодженість.
4. Довіра на рівні ринку — йдеться про репутацію і бренд компанії (або ж персональний бренд), який показує довіру споживачів, інвесторів та інших учасників ринку. Ключовий принцип — репутація.
5. Довіра на рівні суспільства пов’язана зі створенням цінності для людей та суспільства загалом. Ключовий принцип — внесок у суспільний розвиток.

Розглянемо довіру до себе та у взаємостосунках, довіру на рівні команд та організацій.

Довіра до себе та в міжособистісних стосунках

Досліджуючи питання довіри, я виділила для себе такі фактори, що гіпотетично впливають на стосунки: 1) наявність чи відсутність базової довіри; 2) існування сценарію, сформованого під впливом сімейної системи та суспільства; 3) наявність проєкцій/тощо щодо інших людей; 4) досвід.

Базова довіра за Еріком Еріксоном («Дитинство та суспільство», 1996) починає формуватись з перших секунд появи малюка і є способом ставлення людини до світу та оточення. Є такі етапи формування довіри:

1. Чи можу я довіряти світу? (0-1 рік)
2. Чи можу я управляти власною поведінкою? (2-3 роки)
3. Чи можу я бути незалежним? Я — сам (4-5 років)
4. Чи можу я бути настільки вмілим, щоб вижити і пристосуватись до світу? Я в дивному новому світі (6-11 років)
5. Хто я? Які мої переконання, погляди та позиції? Я вже майже дорослий (12-20 років)

Так формується відчуття ідентичності, розуміння себе та оточення.

За Еріком Берном («Ігри, в які грають люди», 2016) майже вся людська діяльність здійснюється відповідно до сценарію, життєвого плану, який заснований на дитячих ілюзіях і батьківському програмуванні. В його розумінні життєвий сценарій є неусвідомленим і формується під впливом батьків і сімейної системи в дитячому віці, а далі розвивається на різних життєвих етапах і проявляється в різних ситуаціях, практично залишаючись незмінним протягом усього життя. Водночас сценарій базується на трьох питаннях стосовно особистої ідентифікації людини та її долі. Хто я? Що я тут роблю? Хто всі ці люди?Водночас Джо Старрідж вважає, що зміна сценарію можлива через внутрішні зміни звичних нам патернів поведінки чи стосунків. І якщо стосунки утворюють сценарний план, вони теж здатні його трансформувати.

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

Понад те — кожен має свій життєвий досвід, який коригує сприйняття навколишньої дійсності. Виникають закономірні питання:

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

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

У будь-якому разі починати треба із себе:

1. Навчитися довіряти собі, вірити в себе. Якщо не можеш довіряти собі, довіряти іншим буде ще складніше.
2. Діяти та жити так, щоб інші довіряли тобі.

Розглянемо приклад. Є спеціаліст, який хоче виступити спікером на конференції з темою, в якій він є досвідченим експертом. І є кілька сценаріїв розвитку ситуації.

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

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

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

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

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

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

Я довіряю собі -> мені довіряти можна, тому інші довіряють мені -> я своєю поведінкою транслюю і культивую довіру далі, наприклад, на рівні команд.

Довіра на рівні команд

Пам’ятаємо, що команда — це група людей, яка об’єднана спільною метою, має взаємопов’язані ролі та взаємодоповнювальні вміння. Команда створює процес та умови бути відповідальними за досягнення результатів. Це команда відданих своїй справі людей, яких поєднують спільні цінності (Джек Велч, «Переможець»). І також пам’ятаємо, що кожен колектив проходить п’ять стадій розвитку. За Брюсом Такменом («Послідовність розвитку в малих групах»): формування -> конфліктування -> нормування -> виконання -> закриття.

Незалежно від того, на якій стадії розвитку перебуває команда, кожен керівник/лідер мав справу з такими ситуаціями:

• коли виконану колегою роботу постійно повторно перевіряєш, при цьому необов’язково знаходиш критичні помилки;
• коли на обговорення простого питання в команді йде набагато більше часу, ніж заплановано, через постійний «пінг-понг» між учасниками;
• коли співробітник не хотів чи боявся озвучити проблему/запитання менеджеру або колезі з різних причин, при цьому створюючи ризики для проєкту або команди.

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

Перший: усі зібрання такого типу проходять дуже швидко і/або майже мовчки. Учасники формально погоджуються з переліком рішень. Питань, уточнень чи заперечень ні в кого не виникає. Все усім зрозуміло. Хоча насправді реальність інша. Тому в результаті по завершенню таких зустрічей відбуваються «закулісні» обговорення, уточнення, коментарі тощо. Як наслідок, пасивні чи активні конфлікти в команді, втрачений дарма час, порушені дедлайни, не виконані взагалі або виконані неналежно завдання. Клієнт незадоволений. Команда демотивована.

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

Взаємна недовіра членів команди, за твердженням Патріка Ленсіоні («П’ять вад у роботі команди»), є однією з вад команди. Недовіра, на його думку, виникає через страх продемонструвати перед всіма свою вразливість, слабкість. І якщо члени команди побоюються відкрито зізнаватися у своїх помилках і недоліках, приховують їх за всяку ціну, то створюється атмосфера взаємної недовіри та підозрілості. В такій ситуації люди не будуть здатні до щирої, відкритої дискусії. Натомість будуть вести обережний обмін нейтральними зауваженнями та коментарями. У результаті ухвалюватимуться одноосібні рішення, що може мати негативні наслідки.

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

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

Отже, як встановити високий рівень довіри всередині команди?

Поради для лідера:

1. Lead by example. Українське прислів’я каже, що риба гниє з голови. А англійське твердить: «Не виховуйте дітей, все одно вони будуть схожі на вас. Виховуйте себе». Якщо лідер орієнтований на довіру в команді, тоді він має бути прикладом, має показати колегам, що довіряє собі, їм, партнерам, керівництву, а отже, будує міжособистісні стосунки так, щоб культивувати довіру на всіх рівнях.
2. Виконуйте обіцянки, будьте послідовними у своїх словах, діях і вчинках. Невиконані обіцянки — потужний демотиватор. Потрібно багато часу, щоб вибудувати довіру, і дуже мало, щоб її зруйнувати. Може бути достатньо однієї невиконаної обіцянки, щоб наступного разу до вас більше не звертались за порадами чи по допомогу.
3. Впроваджуйте ініціативи з побудови довіри. Є безліч тренінгів та спільних ігор, які допоможуть колегам зрозуміти, що таке довіра, чому вона важлива і як її створити на різних рівнях. Часто трапляється, що люди, які працюють разом багато років, не знають простих речей одне про одного. Тому лідер може організовувати воркшопи, тренінги, зустрічі тощо для неформального спілкування команди поза роботою/офісом.
4. Культивуйте культуру відкритого спілкування і прямого зворотного зв’язку. Люди будуть довіряти лідеру більше, якщо відчують, що він відкритий до будь-яких коментарів щодо своїх ідей, проєктів, пропозицій тощо. Лідер має створювати таке робоче середовище, коли здорова, професійна критика є нормою. Це зрештою поліпшуватиме стосунки та результати. Можна періодично влаштовувати письмові чи усні сесії з отримання і надання фідбеку одне одному в межах команди з відповідними висновками, lessons learned.
5. Делегуйте. Мікроменеджмент може стати одним зі способів руйнування довіри. Річ у тому, що довіра — це завжди співпраця, двосторонній процес. Щоб відчути довіру до лідера, члени команди мають відчувати, що довіряють їм. І якщо лідер постійно втручається в роботу колег, вони не повірять, що він на них покладається. Безумовно, не варто самоусуватись чи сліпо вірити. Однак треба періодично відпускати й давати можливість команді виконувати свою роботу самостійно, використовуючи різні рівні делегування. Так, це може призвести до певних невдач, але тоді команда поступово вчитиметься на власних помилках і стане життєздатною та набагато ефективнішою.
6. Говоріть чітко, створюйте середовище прозорості. Коли в лідера репутація прямої, чесної, відкритої та порядної людини, інші вчаться довіряти його словам про себе, свою команду та роботу. Свого часу змінити патерн сприйняття і налаштуватися на довіру до світу мені допомогла установка «що я бачу і чую, те і є насправді».

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

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

Довіра на рівні організації

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

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

Перший: кількість зустрічей стосовно доцільності, формату і впровадження змін на рівні компанії зростає в геометричній прогресії. Обговорення перетворюються в суцільний «пінг-понг». Жодна зі сторін не готова чути іншу, а тому відстоює свою точку зору до останнього, ставлячи під сумнів спільну мету. Кількість «закулісних» обговорень і маніпуляцій зростає. Рішення не вдається ухвалювати спільно. Зміни впроваджуються повільно або взагалі блокуються. Організація уповільнюється в розвитку або взагалі деградує.

Другий: потребу в змінах хоч колектив і піддає сумнівам, але всі обговорення здійснюються відкрито, рішення ухвалюють з фокусом на win-win для всієї компанії. Маніпуляції відсутні. Комунікація чітка. Обіцянок дотримуються. Ресурси використовують ефективно. Зміни впроваджують швидко і з врахуванням потреб усіх сторін. Організація розвивається відповідно до потреби ринку. Додаткові можливості використовуються.

Стівен Кові виділяє 7 «податків» низької довіри в організації:

1. Надлишковість — не потрібне дублювання. Наприклад, надлишкова організаційна ієрархія управління, структури, що функціонально перетинаються.
2. Бюрократія — складні, громіздкі правила, інструкції, процедури чи процеси.
3. Інтриги — використання тактики та стратегії для завоювання влади.
4. Сепарованість — те, що відбувається, коли люди залишаються працювати в організації, але фактично не вважають себе її частиною.
5. Плинність кадрів — коли частка спеціалістів, які йдуть з компанії, хоча їх хотіли б втримати, порівняно висока.
6. Відплив партнерів — велика плинність серед клієнтів, постачальників, дистриб’юторів, інвесторів тощо.
7. Обман — це неявна чесність, саботаж, обструкція, шахрайство, порушення правил.

Може виникнути питання: а що робити, коли починаєш довіряти, а люди продовжують обманювати або ж використовувати це у власних інтересах? Чи варто продовжувати довіряти в такій ситуації?

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

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

Отже, в моєму розумінні для формування довіри на рівні організації потрібно врахувати таке:

1. Формувати довірливі стосунки на рівні керівництва, лідерів. Для досягнення максимальної ефективності керівництву потрібно інвестувати власний час і сили у створення груп лідерів, яким довіряють. Команді лідерів важливо разом розробити єдине бачення діяльності компанії, корпоративної стратегії, а також визначити єдині цінності.
2. Вибудовувати ефективну організаційну структуру відповідно до корпоративних цілей і цінностей. Вона має бути оптимальною для реалізації завдань, відкритою і простою для міжособистісних і міжорганізаційних комунікацій. Політика компанії повинна бути відкритою як для співробітників, так і партнерів.
3. Транслювати, розвивати та підтримувати корпоративну культуру на всіх рівнях. У цьому контексті потрібно вирішити низку завдань: від формування ціннісної пропозиції роботодавця і розвитку employer-бренду, збільшення довіри в міжособистісних стосунках до зростання показників загальної організаційної ефективності.
4. Тримати фокус на людях, ставитись до них як до найбільшої цінності компанії. Незалежно від того, яку роль виконує спеціаліст, яку посаду обіймає, він має відчувати, що йому довіряють, його цінують як фахівця і поважають як особистість. Дуже важливо, щоб існували чіткі критерії оцінювання результативності та діяльності кожного співробітника. Це допоможе вчасно реагувати у ситуаціях, коли хтось намагається привласнити результати роботи інших (свідомо чи підсвідомо), а також не допускати подвійних стандартів.
5. Інвестувати в навчання і розвиток співробітників на рівні всієї організації. Завжди.

Висновок

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

Довіри та розвитку усім!

Що таке спеціалізація для ІТ-компанії? Як це — працювати в аутсорсингу в конкретній ніші?

Я Ігор Цинман, співзасновник і президент компанії AMC Bridge. Працюю в ІТ 28 років, з них 8 в Україні й 20 — у США. У 90-хобіймав керівні посади в компаніях, що займалися розробкою ПЗ в Штатах. А 20 років тому ми з друзями заснували власну компанію, де працюю і тепер. Ми надаємо послуги в інженерній галузі, а наші розробки застосовують у будівництві, машино- та авіабудуванні, в архітектурі та робототехніці.

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

Ринок інженерії та ІТ

Інженерна галузь почала використовувати комп’ютери однією з перших (можливо, на одному рівні з банківською галуззю). Програмне забезпечення тут застосовували для розрахунків, проєктування та виробництва. І одні з найграндіозніших інженерних проєктів минулого — це проєкти NASA. Наприклад, політ Apollo. Цей космічний корабель був одним із найбільш прогресивних інженерних здобутків того часу. Він показав, як можна використовувати комп’ютери для складних обчислень. Програмісти навчали комп’ютери розраховувати оболонки об’єктів, траєкторію руху тощо. Хоча User Interface тоді, звичайно, був практично на нулі.

Зрештою навіть сьогодні деякі промислові проєкти беруть початок у програмах NASA. Наприклад, Solid Edge (один із CAD-пакетів) — це проєкт NASA, який агентство дозволило комерціалізувати та вивести на ринок.

Будівельний бум

Останні 5-6років в інженерній галузі відбувся різкий стрибок. Особливо в будівництві. Все менше людей вважають, що це класно — працювати на вулиці за будь-якої погоди, вручну укладати арматуру та інше. Цифри ж говорять, що в США продуктивність праці в будівництві не зростає з 50-хроків, а 80% проєктів закінчуються невчасно і з перевищенням бюджету.

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

У будівництві вже застосовують 3D-друк (наприклад, друкують цілі будівельні блоки), VR/AR (для дизайну, навчання та контролю за процесом), IoT та AI (ПЗ, що аналізує, чи вдягнув робітник шолом і захисні рукавиці). Наприклад, одна з компаній обладнала робота-собаку від Boston Dynamics камерами, щоб він ходив будівельним майданчиком і знімав усе, що на ньому відбувається, в real time.

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

Наші клієнти та конкуренти

Клієнти — вендори, котрі виготовляють ПЗ самі, як-от Autodesk, SolidWorks, PTC, Siemens, і його користувачі, яким ми допомагаємо кастомізувати готовий продукт, що уже є на ринку, під свої потреби та умови.

На цьому ринку, крім нас, працює ще 10-15 ІТ-компаній.Серед них є аутсорсери зі штатом +10К співробітників, де інженерною розробкою займаються окремі підрозділи, а є невеликі консалтингові компанії на 200-300 людей.У нашому штаті 700+ фахівців. Компаній такого розміру на ринку немає.

Може виникнути питання: чому на потенційно великому ринку так мало компаній? Я пояснюю це високим порогом входу. Щоб увійти на цей ринок і програмувати інженерний софт, потрібно накопичити експертизу. Натомість завжди є багато іншої роботи, яка не потребує вузькоспрямованих знань та досвіду (у нашому випадку такою базою є розуміння математики та геометрії). Якщо говорити про інші домени, то вищий поріг входу є, наприклад, у медичній індустрії. Тут це зумовлено жорсткими регуляційними процедурами та data control процесами.

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

Як ми потрапили в нішу

Насправді перші десять років ми були звичайною аутсорс-компанією і брались за будь-які проєкти. Наприклад, наш перший проєкт був фінансового спрямування. Оскільки всі засновники компанії — люди технічні, ми мали певну недовіру до sales-процесу. Тому, кажучи відверто, до 2010 року отримували нові проєкти завдяки власним контактам. Без професійних продажів.

Але потім усе змінилось. Оскільки у 2001-муми підписали угоду із SolidWorks, згідно з якою до завершення контракту не могли працювати на конкурентів цієї компанії, то ринок інженерії був для нас закритий. Відповідно, коли 2011 року цей замовник пішов, у нас вивільнилось 40% ресурсів. Нам треба було зберегти команду й дуже швидко відновлювати позиції. У цьому допомогла спеціалізація.

Ви це вмієте, а інші — ні!

Пригадую, на одній із конференцій я познайомився із засновником іншої аутсорс-компанії. Коли він дізнався про проєкти, над якими ми працюємо, сказав: «Що тут думати? Ви це робите! Інші — ні. То робіть!».

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

Тим, хто зараз розглядає конкретний домен для свого бізнесу, я б радив звернути увагу на три моменти:

• Динаміка: ринок зростає чи звужується? Якщо зростає, це добре. Отже, там є нові, ще не зайняті іншими компаніями ресурси.
• Суміжні галузі: чи можна застосувати вашу експертизу в суміжних галузях?
• Простір для розвитку: скільки в цій галузі витрачають на ІТ? Якщо 0,1% від цієї суми достатньо для вашої діяльності — це добра ознака, щоб іти в цю спеціалізацію.

Наприклад, в інженерії на ІТ витрачають близько 50-60млрд доларів на рік (це без будівництва), і щорічний приріст становить приблизно 10%. Тому, навіть якщо відсоток від суми буде мізерний, цього достатньо, щоб наша компанія могла розвиватись довгі роки. Також індустрія достатньо широка, щоб можна було зайняти суміжні галузі.

Як закріпитись у вузькій ніші

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

• Не варто ні з ким підписувати ексклюзивні угоди. Ми уклали такий контракт із SolidWorks. Знаю, на якомусь етапі це може бути складно: коли вас десятеро і така компанія погоджується підписати з вами договір, то ви підписуєте все, що дають. Але, наприклад, для нас це закрило ринок інженерії на весь період дії контракту. Відповідно істотно ускладнило зростання. Тепер ми заявляємо, що vendor independent, тож працюємо з усіма виробниками на ринку.
• Визначитись: ви займаєтесь сервісом чи продуктом. Це два різних бізнеси, і я не рекомендував би їх змішувати. Свого часу ми витратили два з половиною роки та досить багато грошей на розробку власного продукту. І тепер розуміємо, що закрити проєкт було правильним рішенням. Окрім того, це спростило роботу із виробниками продуктів: умовно кажучи, вони не бояться, що ми будемо з ними конкурувати.
• Займатись професійними продажами самому. Сейлз і маркетинг — це важлива складова на ринку ІТ. Просто писати хороший софт недостатньо, щоб зростати. І наша компанія — яскравий приклад. Тепер розумію, що нам треба було перейти на продажі мінімум на п’ять років раніше.

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

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

Зізнаюсь, у мене досі є комплекси, що я не професійний сейлз. Але на одній із конференцій спікер Даніел Пінк (автор книги To Sale is Human: The Surprising Truth About Moving Others) озвучив дані, які мене дуже надихнули. Він розповів про експеримент у кол-центрах, яким шукали відповідь, хто краще продає — інтроверти чи екстраверти. З’ясувалось, що екстраверти продають краще, ніж інтроверти, але пік продажів відбувається посередині. Тобто коли ми просто розмовляємо і розповідаємо про свої послуги.

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

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

Ігор (по центру) на конференції BIM World MUNICH, що присвячена цифровій трансформації будівельної галузі, 2019 рік

Ризики та обмеження спеціалізації

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

Отже, ризик перший — у галузі може трапитись криза. Наприклад, криза 2008-2010років найбільше зачепила ринки нерухомості та фінансів. Тому бізнес, який був на них зав’язаний, почувався дуже некомфортно. Як мінімізувати цей ризик?

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

Наприклад, ми починали в машинобудівельній промисловості, а у виробництво зайшли як у суміжну галузь. Водночас могли вибрати й інші галузі, які використовують схожі технології. Наприклад, facility management. Вже є великі організації (аеропорти, торговельні центри, заводи тощо), які за допомогою 3D-сканера сканують свої території, щоб побачити їх реальний план (з урахуванням усіх перебудов, які з’явились за останній час). І це питання безпеки, щоб тримати план евакуації актуальним. Або стоматологія, де для здешевлення протезування вже активно використовують 3D-сканування та 3D-друк.

Інший ризик — у вузькій спеціалізації працює менше людей. Тому варто поставити собі запитання: «Чи є на ринку достатньо талановитих фахівців, яких цікавить ця галузь?». Отримати відповідь на нього нам допомогла українська система освіти. У нас дотепер є багато технічно орієнтованих вишів (на відміну від тих же Штатів). Спираючись на це, ми створили програму, за якою готуємо спеціалістів від університетських курсів через research-проєкти і до роботи над комерційними проєктами.

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

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

Позитиви спеціалізації, Або чому ми тут

А тепер про плюси, які є в роботі на вузькому ринку. І чому ми й далі бачимо тут великі перспективи.

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

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

А в контексті спеціалізації можна поставити такі питання: програмісти знають Revit? Розуміють, як працює об’єктна модель SolidWorks? Чи працювали з Aras? Тоді одразу зрозуміла відповідь, чому саме ми. Звичайно, програмісти загального профілю можуть це все вивчити. Але скільки часу у них це забере? І чи клієнт матиме гарантію, що цих знань буде достатньо? Натомість є змога обрати компанію, яка хоч і дорожча, але добре знає галузь, яка працювала для схожих проєктів і, з високою ймовірністю, дасть бізнесу те, що йому потрібно.

А ще я щиро вважаю, що в Україні та Східній Європі спеціалісти справді люблять виклики. Коли проєкт стає «обкатаним», а завдання мають передбачувані рішення, ми часто чуємо від наших розробників, що їм хочеться складніших завдань, хочеться шукати рішення там, де немає стандартних відповідей.

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

Вузька спеціалізація і пандемія

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

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

Якщо говорити про те, як ми пережили кризу, то, безумовно, спеціалізація нам дуже допомогла. Ось тільки один із прикладів: клієнт, в якого останнім часом великі труднощі, зупинив співпрацю з усіма підрядниками. З усіма, окрім нас. Спеціалізація робить вас незамінними: коли процес довготривалий, то є речі, які знає лише ваша команда. А якщо на ринку 10-15 компаній,то хто розбереться у цьому, окрім вас?

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

С января по май подался на менеджера и/или разработчика в 188 компаний, прошел 52 скрининга, 16 циклов собеседований и тестовых, 2 оффера. Подробности, хаки. Триллер.

Исходные

— Почему вы решили пойти на это собеседование?
— Мне нужна практика разговорного английского ©

Я пишу код года этак с 90-го.Начал с машинных кодов для МК-61, потом basic на ZX/БК0010-0100/"Агат-7″ (клон Apple II+). Ну а дальше понеслось всякое: C++, Delphi, C# два сертификата от Microsoft, Ruby. И по мелочам: Asm, Win API, SharePoint, Python, R со всякой обвязкой типа баз данных, фронта и прочего. Много всего накопилось, разве что TurboVision так и сдох в таск-листе. Ну и Java, только неделя на Spark была. В общем, пишу на всём, что под руку подвернется. Были и перерывы в писательстве, но не очень большие.

Я менеджерю года этак с 2001-го.Туда я пришел джун-программистом и писал коммерческие библиотеки для доступа к данным под Delphi. Было 7 конкурентов, включая бесплатные. Когда я уходил в 2007 уже с позиции Product Manager, самый типичный вопрос на форумах был «А как проще всего смигрировать к вам?». Мы внедрили кастомную билд-систему и автоматические тесты намного раньше, чем это стало мейнстримом. С тех пор я рулил многими проектами, имею рекомендации от нескольких CEO. Раз пять переходил с менеджерских позиций на программерские и вырастал обратно. Как максимум — 17 человек удаленно.

В 2010 вместе с Димой Снисарем стартовали наш собственный бизнес IT-Boost по обучению айтишников психологии. Бизнес успешно провалилсяпо экономическим причинам, при этом я многое оттуда вынес. Опыт очень разнообразный, можно почитать часть в «Как меня увольняли и прочие байки».

При этом как программист я не очень глубоко погружаюсь в область. Например, не могу по памяти рассказать особенности работы GC и чем версия х.3 отличается от х.2. И с учетом багажа языков я вечно путаюсь в том, как в конкретном языке писать switch. Это мне не мешает видеть разные решения с их плюсами и минусами и уметь их объяснить лучше, чем «вот это правильно, и всё тут».

Как менеджер... Тут многое нужно сказать, кому хочется подробностей — читайте «Почему многим хочется стать менеджером и это не всегда хорошая идея».

Итого по состоянию на январь 2020:

• Как программист я проигрываю узкому специалисту всухую. Не, я тоже могу любого программиста завалить на собесе, тут кто первый халат надел, тот и доктор. «Почему вы не знаете основных контрибьюторов библиотеки, которой пользуетесь каждый день?» Или «расскажите-ка о ACID в приложении к реальному миру». Это если в regex email не лезть.
• Как менеджер... У меня не идеальный английский, особо плохо с пониманием акцентов и живой речи в группе по скайпу. Еще нет опыта управления местной командой. Об этом позже. Ну а опыт выступления на 15 конференциях плюс миллион прочтений на ДОУ вообще значения не имеют.
• Как психолог... я знаю больше среднего программиста, при этом толковый второкурсник с психфака знает и умеет больше. Как мне кажется. Ну, это моя вера такая. Убеждение. Не проверял.
• 42 года, одна жена, две кошки, трое детей — 16, 10, 6.

В Канаду я переехал в июне 2019 по intracompany transfer: специально под меня создали филиал, и я перешел одним единственным сотрудником, в должности VP of Engineering. Ну, у нас еще инвесторы были из Канады и один подпроект был в Монреале. Это отдельный триллер.

В январе я наконец-то начал смотреть налево активно. Почему:

• пять лет на одном проекте, надоело;
• подпроект в Монреале заканчивался;
• ситуация на проекте была плюс-минус. То есть покидать тонущий проект мне тяжело, а вот плывущий — вполне ок. А тут новый, седьмой за пять лет, босс наконец-то въехал в проект;
• выяснилось, что компания протупила местное законодательство. Например, меня не застраховали, что очень неправильно с точки зрения закона. Это вряд ли по злому умыслу, скорее, по незнанию. И если бы это всплыло, то пошли бы к кому? Возможно, к сотруднику в Канаде с наибольшим званием. То есть к VP of Engineering!
• обнаружил, что моя зп VP of Engineering более чем достижима на программерских ролях, плюс еще страховка, бонусы и так далее. Можно даже +20% получить, побегав по собесам;
• с продлением визы тоже всё было сомнительно. Что-то начальство этот процесс всё откладывало и откладывало, хотя время еще было;
• где-то у меня есть установка «сначала развод, а потом уже ищу замену», которая не давала мне бегать по собеседованиям. Неконструктивно, но облико морале;
• с июня у меня были ежедневные синкапы в 5 утра. Мне это более-менее, я жаворонок, но всё равно.

Я сформулировал, что мне интересно:

• Люди и их взаимодействие. Оптимизация процессов. Поиск узких мест и их улучшение. Теория ограничений и её следствия. Балансировка интересов бизнеса, разработчиков и юзеров. Через развитие людей к развитию компании.
• Что-то однозначно полезное энд-юзерам. То есть «лучше поиск», «быстрее открывается» и «удобнее конструктор» это лучше, чем «продвинутая реклама».
• Информационная безопасность. Никогда не имел возможности туда закопаться по-настоящему.

Обратите внимание, что там нет ни слова о выборе «код» или «менеджмент». Я затыкаю собой те дыры на проекте, где сейчас никого нет. Некому девопсить и нельзя нанять? Я тут. Некому писать на экзотическом языке? Ок, это ко мне. Нужно требования собрать и отчет написать? Ок. И так далее.

Вот в этой точке я вышел на рынок труда в январе 2020.

Цель

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

Итак, «кем вы себя видите через три-пять лет»:

1. Вид на жительство в Канаде. Я по-прежнемухотел бы построить Канаду в Украине, но что-то новости одна хуже другой. Меня пугали, что спадут розовые очки... Ну, я вижу тут и плюсы, и минусы, в целом мне в Канаде очень нравится.

2. Монреаль. Город нравится всё больше, хотя я уверен, что есть и не хуже. Люди очень доброжелательные и вежливые, а это для меня из детских травм — «не иди на эмоциональный конфликт». Цель «Монреаль» конфликтует с целью «ВНЖ», так как для Монреаля нужен либо французский, либо два переезда.

3. Менеджерская или SM/Agile роль. Я этого в себе не чувствую, но всё-таки пишу о том, что мне интересно, и я редко пишу на тему «а вот посмотрите, как интересно можно Lambda использовать».

Одна из школ достижения целей противопоставляет достигаторство и попоморщество. Школасама по себе со мной малосовместима, и при этом я могу использовать несколько приемов из нее. Так вот, для достигатора нормально и правильно идти к нескольким целям одновременно. Даже если одна-две обломаются, это не катастрофа, у меня есть еще цели в запасе. Да и список хорошо бы обновлять время от времени.

Январь

Первая попытка. Хорошая компания с отличными отзывами, интересным проектом, отлично налаженными процессами, высокой зарплатой. Я не готовился к тому, что вот сейчас минут за 40 мне нужно будет нехилый код наколбасить в непривычном мне сайте, и ушел в привычные для меня рассуждения про граничные условия типа «а какая нагрузка ожидается; что делать если точки совпадут; что из библиотек могу использовать?». В общем, с очного собеса я ушел в двойственных чувствах.

С одной стороны, я прошел блестяще 6 из 7 этапов, включая онлайн-кодинг, с другой — на втором кодинге явно облажался. В пятницу днем они мне позвонили, но я был на другом собесе. На автоответчике оставили предложение созвониться, когда у меня будет время. Я позвонил им сразу же, но они не ответили, в Монреале в пятницу после обеда вообще редко кого на работе можно увидеть, кмк.

Все выходные я провел как на иголках в предвкушении подтверждения. В понедельник ближе к обеду созвонились. «Спасибо, мы приняли решение двигаться с другими кандидатами. Нет, обратной связи не делаем». Было очень обидно. Впрочем, эта компания очень конкретно влипла с ковидом, и если бы мы начали оформлять визу, я даже не знаю, чтобы со мной было.

Я переписал резюме и оценил его как «сказочно хорошо получилось»: коротко, по существу, с кучей «плюшек». И начал рассылать. 20 лет опыта втиснуть на два листа само по себе сложно.

На одном собеседовании я видел непривычного мне CEO. Ну знаете стереотип CEO? Костюм, галстук снят исключительно для повышения демократичности. Тут тоже был в костюме и без галстука. Костюм спортивный, лицо помятое. Представьте себе типичного доминошника под гаражами — и вот он. Только рулит компанией из 100 только программистов, плюс еще производство. Внешность обманчива.

Одна вакансия с пунктом «Смирение для тебя естественно» («Humility is natural to you»). Даже не знаю, как это перевести точно, но настораживает. У меня это слово ассоциируется только с БДСМ.

Попыток 17, скринингов 9, циклов собесов 3.Больше я, пожалуй, не тянул, совмещая с fulltime-работой. Естественно, за каждой попыткой стоит история.

Два отказа — визу не делают.

Один отказ — по информации от инсайдера, вакансию запаузили.

Один отказ — дубль в разных рекрутинговых агентствах.

Один отказ — слабый английский. По инфо от инсайдера — получил метку «не умею формулировать свои мысли». Обидно, это умение, которое я считаю у себя сильной стороной.

Один отказ — я явно продолбал рисование алгоритмов на доске. Изобразил простейший вариант для начала, а развить его мне не дали.

Менеджерские вакансии — как в песок. Или отказы, или тишина.

Красивая диаграмма, которая так всем понравилась у меня в FB, сработала примерно никак. Ни один рекрутер не пропускал ее на следующий этап. Если же я ее показывал, то её все хвалили и отодвигали в сторону, не разглядывая. В общем, скромнее надо быть. Индивидуальность редко востребована для программистов и тимлидов.

Эмоционально накал растет. Отказы и ингор бьют по самооценке. Непонятно, какой язык учить, да и вообще будущее в тумане. А с моей тревожностью неопределенность триггерит. Лендлорд долбит повышением цены на аренду.

Одно радует: через две недели должна стать понятнее моя цена на канадском рынке труда, так как придут результаты попыток.

Спин-офф: аренда в Квебеке

Когда в мае 2019 я еще из Харькова подписывал аренду дома в Монреале, прочитал контракт. Вот больше всего запомнилось:

• курить нельзя;
• кальян тоже нельзя;
• курить нельзя в доме и кругом;
• в доме и кругом курить нельзя;
• в гараже, на лестницах и вокруг дома курить нельзя;
• ночью тоже курить нельзя. И в другое время суток тоже;
• на бэкярде курить нельзя.

Вот очень похоже на тесты программистов, написанные по команде «протестируй всё» без оглядки на дальнейшую поддержку.

Я потом выгреб дофига бычков с бэкярда.

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

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

Еще есть ловушка, про которую нас предупредили друзья. Говорят, за полгода до окончания аренды вам придет письмо о повышении платы со следующего арендного года. И внутри письмо с бланком и конвертом, что вы (не) соглашаетесь с повышением. Ну-у-у, вдруг вы не хотите повышения на 5%? Тем более, что по закону нельзя больше, чем на 2.5? Так вот, ответ на этом бланке подтверждает ваше согласие, вне зависимости от того, что вы там понаписывали. Если что — можете идти в суд и потягаться с корпорацией, имеющей представительство по всей стране и с профильными адвокатами на ставке. Короче, правильное действие — отправить отказ письмом, а чек сохранить. В ответ на это они скинут до 3.5 и предложат идти в суд. В суде, кстати, можно и до 2.5 доторговаться, вопрос во времени и желании. Числа тут по памяти, могу немного ошибаться.

Февраль

«У нас котенок от пылесоса сначала бегал, а потом ничего, втянулся» © не моё

Собеседовался на менеджерскую позицию в один успешный стартап в Эдмонтоне. Классный проект, живые люди и задачи, понятная бизнес-модель. Опять же, близко к производству, что мне импонирует. Команда растет (12 -> 20), а разработчики хотят оставаться в коде, пробовали найти кого-то, кто бы менеджерил. Вроде везде хорошо поговорили, обещали еще созвониться, но они исчезли и перестали отвечать на письма.

Кроме всего прочего, на сайте Альберты, посвященном визам, написано прямым текстом «если вы хотите нанять иностранца на менеджерскую роль, позвоните нам, и мы расскажем, как нанять местного.» Я предложил «наймите меня программистом, а я буду участвовать в совещаниях», и, как мне сказали местные, это могло быть красным флагом. Человек, предложивший обойти закон, от себя отталкивает. Было обидно. Кстати, канадская нефтянка после падения цен на нефть стала заведомо убыточной. Не знаю, что бы со мной было, если бы в феврале начали оформлять визу.

Еще у меня был запасной вариант: я когда-то менеджерил на почасовке другой стартап из Эдмонтона. Потом у них бизнес пошел, они сдвинули центр разработки из Европы к себе. Осенью 2019 они мне сделали оффер на программиста, я к ним даже в гости слетал. Но по итогу решил вернуться в старый проект, поскольку, если бы ушел — проект бы сдох. Обращаться к ним — это переступить через себя. Но когда я понял, что ситуация не складывается, то написал им еще раз типа «а оффер еще в силе?». На что получил «сорри, у нас сейчас нет позиций на твою квалификацию». И понимай это, как хочешь — или выше, или ниже. Не важно почему, важно, что запасной вариант полностью провалился.

На официальном визовом сайте есть рекомендация начинать оформлять визу за 30 дней до окончания старой, но вообще процесс занимал 120 дней в среднем. В конце января мы эту границу перешли, и было непонятно, какую визу оформлять. В конце февраля стало понятно, что на старый проект визы наверняка не будет.

Из разговора с одним канадским директором: «Наши клиенты — корпорации с многодесятилетним опытом на рынке. С отлаженным бизнесом и процессами. Работает — не трогай? Так вот, пришла беда откуда не ждали, они не могут нанять людей на работу с бумагами. Как только человек понимает, что придется работать с бумагой, а не компом — сразу же увольняется».

Переписал резюме, сделал его гораздо более программистским, а менеджмент вообще попрятал. Было «VP of Eng 2 года», стало «за пять лет в компании был и программистом, и менеджером».

Сроки жмут, я явно не так востребован, как мне бы хотелось. Ну, тут понятно, что делать: обрабатывать ошибки и пробовать еще. Одно радует — через пару недель будет определённость.

Попыток 13, скринингов 6, циклов собесов 2.

Спин-офф: имитатор

Собрал из комментов и обрывков историй, услышанных от знакомых. Сам сталкивался только частично, когда нанимал.

В большую компанию на собес на мидл приходит сеньор под чужим именем и благополучно проходит все этапы. На работу выходит не он, а тот джун, чьё имя использовали.

Дальше варианты:

• схему раскрывают, джуна выгоняют. Невелика потеря, даже если ему не заплатят за эту неделю-другую-третью. А скорее всего, заплатят, крупной компании проще сказать «не прошел испытательный», чем доказать, что месяц назад на собеседовании был кто-то другой.
• джун работает и отстегивает процент сеньору. Его результаты не настолько ужасны, чтобы менеджер мог его легко выгнать. В больших компаниях тимлид/ПМ часто вообще не обладают властью на увольнение. То есть нужно приложить усилия, а HR и топы это воспринимают как «ты не умеешь мотивировать и вообще работать с людьми». Если тимлид/ПМ еще и за бюджет проекта не в курсе, так ему часто себе дешевле вообще не поднимать вопрос. Тем более, что увольнение мидла на сроки сдачи проекта влияет только неочевидно.
• джуна увольняют. В западной компании он тут же заявляет «это из-за национальности/пола/ориентации» и получает денег. Возможно, больше он в индустрии не работает, но и пофиг.

Факторы успеха:

• этапов собеседования много, собеседуют не те люди, которые потом будут с человеком работать.
• у программистов часто плохая память на лица. Особенно если непривычная раса/национальность. Все ли могут с уверенностью описать тех, с кем собеседовались месяц-полтора назад?
• документы на собеседовании предъявить не просят, а если даже есть проходная — это исключительная редкость, чтобы кто-то сверял фото с лицом.

Неправдоподобно? Когда запостил у себя в фейсбуке, часть людей сказала, что это бред и так быть не может, а часть: «Да, у нас вот это было, я видел и подтверждаю».

Март

«Страх — это маленькая смерть, влекущая за собой полное уничтожение» © Фрэнк Герберт

Где-то в конце зимы было в школе родительское собрание: «Когда Катю не понимали, она просто повторяла с повышением громкости. Потом еще раз. И еще. Всё громче. На русском. У нас в классе нет никого русскоговорящего, включая учителя. А теперь пытается сказать по-французски, доросла».

В начале марта я начал подаваться везде. Вот тупо на все вакансии, которые хоть как-то подходят под мой профиль. Канада, Ruby±, dev/TeamLead. Проверку компании начал делать только поверхностную.

Одна компания дала тестовое. У компании есть миссия и принципы, и они действительно есть, а не для галочки, очень впечатляет. Например, вместо привычного «да, у нас есть миссия, но я ее не помню» была пачка вопросов на совместимость. Про тестовое в двух словах «вам со складов приходят по веб-сокетам пакеты [{<название склада>, <название товара>, <изменение с прошлого пакета>}]. Напишите сервер, который бы предупреждал оператора о максимально большом количестве проблемных ситуаций. Интерфейс на ваше усмотрение — от реакта до SQL. Задавайте вопросы».

Очевидная ловушка — приходят только изменения, нет возможности получить ни начальные данные, ни провести ревизию, поэтому две трети аналитики попадает в раздел «а давайте улучшим протокол». Потратил я несколько дней, описал всё, отправил на проверку из расчета, что мне что-то скажут про протокол и вообще опишут, насколько тщательно нужно вылизывать проект.

Всегда есть что улучшить, стоит ли это делать для заведомо мертвой задачи? В ответ получил «н-у-у, мы ждали подробной инструкции, где и что запускать, например, через Docker. А по протоколу — это специально так, проявите креатив». Ок, еще за день-другой улучшил всё и получил «для нас важно быть честными, так что говорим как есть. Мы решили нанять парня, который раньше с нами работал. Он франкофон, да и вообще мы его знаем». Обидно, я довольно мощно вложился в тестовое.

Как мне объяснили местные друзья, во франкофонную компанию возьмут неместного только от безнадеги. Уверен, что в этом есть и правда, и преувеличение.

Много вакансий с формулировкой «почему вы хотите работать именно у нас?», а некоторые даже с «и нигде в другом месте?». Такое может в легкую написать Google/SpaceX. Могу понять, если такое напишет TP-Link/Yahoo/TwoCows. Когда это пишет компания, о которой ни разу не слышал... меня это отпугивает.

Рекрутинговая компания Quantum World Technologie написала/позвонила мне минимум 15 раз. Предлагали работу в США. Каждый раз говорил им, что у меня нет визы и просил поставить пометку рядом с моим профилем. Звонят по-прежнему, с разных номеров.

Рекрутинговая Randstad звонит тоже многократно. «Вы профессионал в .Net/SharePoint». В резюме четко написано, что прошло больше 10 лет с тех пор, как я на них писал. Пофиг. Однажды сказали: «Нашему клиенту нужны специалисты по Angular. Вы на нем не писали, но давайте допишем вам в профиль?». Местные говорят, что это самые дорогие рекрутеры на рынке. Еще говорят, что местные рекрутеры склонны человека трудоустроить, а через год его же перенанять. Поэтому местные работодатели к рекрутерам не любят ходить.

Многие используют HackerRankдля тестирования. Я за 21 год с окончания универа писал сложные алгоритмы примерно два раза, поэтому после получения приглашения на тестовое в HackerRank сделал паузу на несколько дней и полез туда восстанавливать забытое. И правильно сделал, поскольку к интерфейсу нужно привыкнуть и научиться писать в нём тесты. Выяснил, что задания максимальной сложности я делаю за день-два. Для пробы сдал пачку заданий из разных областей на Ruby/JS/Python — норм, готов. На собеседованиях обычно дают задания куда проще, чтобы в час влезли с запасом.

Многие используют Calendlyдля назначения собеседований. Удобный сайт-надстройка над Google Calendar, где интервьюер предлагает доступные слоты, а кандидаты их занимают. Очень рекомендую тем, кто сталкивается с «договориться с пятью людьми о пяти звонках в один день».

В одной компании по результату собеса сказали, что у меня архитектура слабовата. То есть проектировать её у нас вы всё равно не будете, но каждый сеньор должен уметь расписать высоконагруженную систему. Ок, засел за учебники. Вообще, в марте я очень конкретно погрузился в теорию. В июне эту компанию купил Google. Купил и закрыл. Не знаю, что бы со мной было, если бы я прошел.

Еще в одной компании был автоматический скрининг. Робот задает вопрос, вы должны записать короткий видеоответ. Вопросы плюс-минус стандартные, под кожу залазящие. «Расскажите о самой серьезной ошибке», «чем вы гордитесь», «конфликт какой у вас был?», «почему хотите работать у нас?» и так далее. Всё это в пулеметном темпе. Через несколько дней пришло стандартное письмо: «Мы сейчас очень заняты, но потом посмотрим обязательно!». И еще через недели две стандартный отказ.

Опять переписал резюме. В каждую компанию — отдельное Cover Letter с раскрытием, почему я подхожу под эту вакансию. Очень много компаний требуют не только резюме, а еще и подробного заполнения анкеты у них на сайте: места работы, технологии, обязанности и прочее. Сайты при этом часто глюкавые и неудобные. Как понимаю, это убийцы LinkedIn сражаются за рынок.

12 марта я детей в школу не отпустил, на всякий случай. Из школы позвонили и спросили почему. 13-гообъявили, что детей в школы не принимают. 16-гоуже был локдаун. Рынок труда обрушился. Вакансий почти нет, а те, что есть: «ой, мы забыли отключить».

Сначала мы начали зарядку. Кошка появилась позже. И даже пентаграмму модифицировать не пришлось. И вообще, кто не делал зарядку ради красоты, будет делать ее, чтобы спина меньше болела.

Март, отказы и тишина, тишина и отказы. Старая компания разваливается, виза заканчивается, формально в мае мы должны покинуть Канаду, самолеты не летают, в США нельзя. У Канады не так много сухопутных соседей, так что хоть вплавь. Если не покинуть — мы нарушители визового законодательства и невъездные в цивилизованные страны. Еще выяснилось: чтобы увезти кошек в Европу/Украину, нужны свежие прививки от бешенства и титры на антитела. В Канаде титры сделать сложно, а во время локдауна — вообще невозможно. То есть кошки невыездные.

Нервничаю, тревожность шкалит, прекратил общаться с людьми в сложных состояниях, так как тут не до других, тут бы свою крышу удержать. Спойлер: это не тупик. Цитата по памяти «тупик — это близкая неминуемая смерть. С остальным можно и нужно работать». Катастрофизация, тревожность и депрессия — с детства привычные гости в моей голове. Я знаю, что с ними делать и как их не передать детям.

Одно хорошо, через пару недель станет ясно, подействовал ли карантин, сайты очистятся от забытых вакансий, инвесторы вылезут из норок.

Попыток 45, скринингов 14, циклов собесов 3.

Спин-офф: аренда в Квебеке — вторая ловушка

В договоре про аренду был пункт про автопродление и куча деталей, при которых арендодатель может в этом автопродлении отказать. Причины довольно понятны: цены на аренду растут ракетой, а по закону есть лимит в %%, на сколько можно поднимать в год. Еще была интересная табличка, привожу её целиком. Похоже, это стандарт для Квебека. Тогда я в ней ничего особого не увидел. Ну, знаете, три недели до переезда без отрыва от работы, дедлайны — что-то упускаешь.

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

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

Мы написали в локальные группы. Мы обратились к более опытным друзьям. Мы написали в специализированный суд. Я полистал законы. Результаты:

• «Они козлы, но их адвокаты вас съедят и не заметят — у них специализированные адвокаты на ставке как раз для таких случаев. Ну и отметка у вас будет, что вы судились с арендодателем, вам потом будет сложнее снять жилье» — это если просуммировать мнение не спецов.
• «Вообще мы советуем соблюдать условия договора либо найти арендаторов вместо себя, либо договориться полюбовно. Ваша тяжелая ситуация не должна влиять на выполнение договора. Еще вы можете обратиться в суд» — это из приемной того самого суда. Фактически закон оставляет возможность разорвать контракт, только если кто-то умер или развод из-за семейного насилия, подтвержденного полицией.
• «Мы готовы вас отпустить за сумму, эквивалентную трехмесячной аренде» — от арендодателя. Я арендовал довольно дорогой дом в хорошем месте, за три месяца это примерно 5200 USD подарить.

В общем, немного сгущая краски, в начале апреля у нас была ситуация:

• Компания, которая меня привезла в Канаду, сокращает всех сотрудников, включая меня. Есть шанс обратного найма, но чем дальше, тем меньше этот шанс.
• Виза привязана к этой компании и истекает в начале июня. Мы должны покинуть страну, но не в США, и самолеты тоже особо не летают. В общем, плывите так. Сгущение красок именно здесь. Законы потом адаптировали и дали больше времени. И даже финпомощь и медстраховку.
• Я не имею права работать на нового работодателя до оформления бумаг. Новая работа ищется с трудом — все попрятались от ковида.
• Арендодатель нас крепко держит.

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

В итоге я написал письмо на топ-менеджера, в котором подробно описал ситуацию «вот мы тут бедные-несчастные, всегда платили вовремя, виза заканчивается, мы должны покинуть страну, хотим это сделать, не оставляя за собой долгов, давайте мы вам заплатим за оставшиеся месяцы авансом?». Это сработало!

Что могло повлиять:

• вошли в положение. Честно говоря, не верю — предыдущие попытки не срабатывали;
• прикрытая угроза «свалим из страны, не заплатив и за май-июнь, ищите нас потом»;
• предложение аванса — у них как раз был кризис неплатежей, там 80% арендаторов задержали платежи, а я предлагал живые деньги.

В итоге с меня попросили копию визы и письма об увольнении, я заплатил авансом, и всё закончилось хорошо.

Апрель

олег уволился с работы
душа полна различных чувств
как будто прямо с шеи камень
упал на палец на ноге
© не моё

Работа на старом проекте замерла, только минимальный саппорт и всё. Зарплата, по согласованию сторон... джуны в Харькове зачастую получают больше. Каждый день смотрю за графиками Доу-Джонса и заболеваемости. Массово приходит понимание, что это всё надолго. К концу апреля это поняли даже школы и наладили плюс-минус нормальное дистанционное обучение. Дочки ходят на акробатику по зуму. Инвесторы и работодатели выжидают.

Диалог на скрининге:

— Почему вы хотите работать в Монреале?

— Мы выбрали этот город после поездок по шести странам и четырем городам в Канаде. Нам нравится Монреаль.

Диалог на другом скрининге через полчаса:

— Почему вы хотите переехать в Оттаву?

— Мы хотим англоязычную провинцию.

Оба диалога — правда, но не истина. Истина — нужна виза, и срочно. А для визы нужна работа. А для работы нужно, чтобы взяли хоть куда-то.

Часть компаний говорит «мы визу не делаем» с подвариантами «вообще не охота головняк» и «других кандидатов сейчас много». Часть вообще: «сложные времена, мы сейчас просто набиваем пул».

Мы тоже осознаем, что локдаун надолго. Я ввожу дома график. Зарядка-завтрак-обед и так далее по часам. Иначе много конфликтов и общей подавленности. Нужно было что-то формообразующее.

Виза истекает второго июня, времени осталось чуть-чуть, пробую снизить ожидания по зарплате. Поскольку подаюсь много куда, то экспериментирую с суммой. Главное записывать, кому что сказал.

На собеседованиях на вопросы по архитектуре очень хочется сказать YAGNI: «Вы не Google, для большинства проектов такие сложности не нужны». А потом вспоминаешь, с кем общаешься и какие у них нагрузки... Нет, им все эти паттерны таки нужны, а это мои десятилетия в стартапах сказываются.

Созерцание дзена креслоцараптором

Спин-офф: скользкие вопросы на собеседованиях

Примеры:

— У вас конфликт с сотрудником. Ваши действия?

Правильный ответ из учебника по менеджменту: «Ищу рациональное зерно, точки соприкосновения, win-win». То есть всё хорошо в теории, но если я при этом злюсь, то хрен у меня выйдет. Учебник по менеджменту вообще предполагает, что на работе эмоций нет. Программисты же не пукают, да?

Правильный ответ из учебника по психологии: «Стабилизирую свои эмоции, постараюсь подумать, что мне хотели сказать». То есть думаю не о проблеме, а об эмоциях и отношениях в рабочее время, что херня с точки зрения «этого нет в служебных обязанностях».

Правильный ответ из учебника по собеседованиям: «Сообщу своему боссу/HR». То есть с каждой мелочью бегаю к начальству, ну херня же. «Мне не нравится музыка, которую он слушает». Начинать правильнее с просьбы сделать потише, кмк.

— У вас есть автотесты, которые похожи, но не совсем. Что вы сделаете?

Правильный ответ из учебника: «DRY везде! Объединяйте повторяющиеся блоки, никакой копипасты, её сложно поддерживать!».

Правильный ответ из другого учебника: «У вас тесты становятся нечитаемыми, а общая часть перегружена IFами. Это всё сложно читать и поддерживать! Правильные тесты должны быть понятны без изучения кода на пяти экранах!».

— У вас задача написать классы для Прямоугольника и Квадрата. Как вы построите иерархию? Кого от кого унаследуете?

О-о-о, тут масса вариантов. Даже перечислять не буду. И все можно разгромить. В общем, нужно писать правильно, а неправильно писать не нужно!

— Вы менеджер, вам нужно построить архитектуру. Что вы делаете?

Правильный ответ из классического учебника: «Сбор требований делегируй бизнес-аналитику, потом передай архитекту, проверяй результаты. Если этих ролей нет — делай сам. Потом оформи в презентацию и покажи стейкхолдерам». Быстро, четко, есть ответственный. Лидерство, авторитет, иерархия. Полная херня с точки зрения отношений в команде, очень легко получить потом работу «на отцепись».

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

Это только примеры вопросов, на которые нет правильного ответа. Любой ответ может быть истолкован как «за», так и «против». На мой взгляд, человек, который на основе этих данных готов дать ответ, уже неправ, там всё субъективно и контекстно-зависимо. Но спрашивают.

И есть еще одна ловушка. Спрашивающий обычно принимает решение «он знает/не знает» в первые секунды. Поэтому если начать с водянистого «здесь есть много подходов и нет серебрянной пули», то очень легко получить вывод «нихера не знает, а за словоблудием пытается это скрыть». Так что, если ты начал с того, что важно для собеседующего — тебе повезло. Если с чего-то другого — увы. Это попадание в культурный код. Что очень хорошо, когда у тебя есть выбор, куда идти. И плохо, когда нужна любая работа вот прямо сейчас.

Хотя можно еще использовать для подсказок язык тела. Что почти херня при онлайне.

Итого

В мае заканчивается мой IELTS, сданный два года назад. Я новый назначил на начало мая, но его отменили. Предложили либо в июне в Торонто (8 часов на машине), либо в Монреале в июле. Выбрал Торонто.

Обсудили с женой покупку кошачьего туалета. Решили, что пока не знаем, куда и как переезжать будем. Вообще, все обсуждения семейных планов уже который месяц начинаются с «вот как будет ясность с работой, так и будет понятно».

Одно хорошо, такая неопределенность не может длиться долго. Там либо будет оффер и виза, либо мы таки улетаем и это совсем другая сказка.

Попыток 78, скринингов 14, циклов собесов 4.

Это не конец. Продолжение — в следующей части статьи. Скоро на DOU.

Я уже 35 лет в IT, из них больше 20 — в разработке, в основном в роли играющего тренера. Занимался всеми видами поддержки, информационной безопасностью и построением процессов с обязательным погружением в бизнес заказчика. Преподавал, был ментором, вел тренинги и читал, но самое главное — участвовал в формировании команд, которые могут сделать практически все, причем с удовольствием. Потому что им нравится их работа и нравится работать вместе.

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

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

Универсальность как вечная ценность

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

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

Отклонения в сторону специализации начались в индустриальную эпоху, особенно с возникновением конвейерного производства. Один мой знакомый всю жизнь прикручивал заднюю ножку к диванам на мебельной фабрике. Было скучновато, хотя модели диванов периодически совершенствовались. Когда предприятие закрылось, не выдержав конкуренции, знакомому было не так-то просто найти работу. Сейчас такие рутинные операции подлежат роботизации в первую очередь, а человеку остаются творческие специальности. Например, информационные технологии в целом и программирование в частности.

Если посмотреть на историю IT, вначале языки программирования были похожи на ту самую палку первобытного человека. С помощью машинных кодов и Ассемблера можно было показать все, на что способна ЭВМ. Правда, работать с их помощью приходилось долго, и для разработчика это было совсем неудобно. Поэтому довольно быстро возникли языки высокого уровня типа PL, REXX или Фортран. При этом следует помнить, что язык программирования — такой же язык общения, как и любой другой. Просто он позволяет нам коммуницировать не только друг с другом (для этого он тоже годится), но и с машинами. Т. е. расширяет круг наших контактов, делая способность к общению более универсальной.

Есть программисты с большим опытом, которые вписались в проекты, рассчитанные на много лет, скажем, в банковской сфере. Там существуют программы, которые могут подолгу оставаться без изменений, поскольку устраивают всех, кто с ними непосредственно соприкасается. В такой нише можно относительно спокойно кодить вплоть до заслуженного отдыха. Но, с одной стороны, количество таких мест ограничено. С другой — хотели бы вы оказаться на одном из них? Даже если вас не пугает скука и очень привлекают деньги, которыми обычно и мотивируют заниматься немодными технологиями, готовы ли вы пойти на такой риск? Ведь если до пенсии вам не год и не два, велики шансы, что работу искать еще придется. А программист с большим опытом и маленьким набором возможностей — самая противоречивая фигура на рынке труда. Она может вызывать удивление, но вот желание познакомиться ближе в рамках рабочего проекта — очень изредка.

Все остальные программисты существуют в совсем других условиях: любой, кто обратился к современным технологиям, будет вынужден постоянно учиться. Либо углубляя знания по выбранной изначально специализации, инструменты которой будут кардинально меняться (вспомните С, С++, С#, Golang), либо внимательно глядя по сторонам. Лучше, конечно, делать и то и другое.

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

Сами технологии сейчас развиваются именно в направлении синкретизма, плотного пересечения и даже частичного слияния самых разных направлений. Возьмем, к примеру, MLOps — объединение технологий машинного обучения и подходов к внедрению разработанных моделей в бизнес-процессы. Очень важно, что новая специфическая область потребовала и нового способа организации сотрудничества между представителями бизнеса, математиками, ML-специалистамии IT-инженерами. Это не было бы возможным, если бы все они не говорили на одном языке — т. е. не осваивали смежные со своей основной специализацией дисциплины. Хотя бы трех (допустим, четвертая — та, из которой человек пришел в проект, им уже освоена), причем на уровне как терминологии, так и образа мышления. Интересно ли работать в MLOps-проекте? Думаю, мало кто откажется. Возьмут ли туда человека, не готового расширять сферы компетенций? Вряд ли, даже если в своей узкой нише он давно стал блестящим профессионалом.

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

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

Поэтому максимальная эффективность достигается, когда каждый участник команды понимает не только, что он делает в проекте, но и зачем он это делает. Как правило, это невозможно без понимания доменной области, т. е. сути бизнеса клиента. Значит, от программиста уже требуется некоторая универсальность знаний.

Я не утверждаю, что каждый IT-специалист обязан разбираться в бизнесе. Но это очень полезно для работы, общения с коллегами и понимания происходящего на разных уровнях. Вообще, серьезная специализация началась с выделения администраторов баз данных. Тогда впервые понадобились люди, которые бы глубоко знали специфику написания скриптов и конфигурирования СУБД различных производителей. Но в итоге такая специализация сработала плохо. Как только появились DBA, многие разработчики решили, что писать код можно как угодно — придет администратор и все оптимизирует. Но отвечать на вопрос «Почему так медленно работает SQL-запрос?» всем быстро надоело. Кому интересно разбираться, у разработчика ли кривые руки или DBA не умеет настроить сервер? Сути проблемы это не меняет.

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

Примерно то же произошло при разделении фронтенд- и бэкенд-разработки. Специализация всегда позволяет глубже проникнуть в тему, но платить за слишком плотное погружение приходится сужением кругозора и затрудненной коммуникацией с коллегами других специализаций. Конечно, одно из наиболее очевидных проявлений универсальности — фулстек. Если человек хочет лучше понимать, как работает архитектура в целом, или, наоборот, разобраться, как пользователь взаимодействует с системой, — это наверняка позволит ему обходиться в межцеховой коммуникации без дорогих и неудобных переводчиков. Даже если в основном он продолжит работать именно как фронтенд- или бэкенд-разработчик. Здесь-то мы подходим к главному: писать код, который работает оптимально — намного круче, чем просто писать код. Поэтому тебе не должно быть все равно.

Кого можно назвать универсальным

Универсальный специалист — не тот, кто однажды освоил еще одну незнакомую технологию. Он постоянно следит за современными трендами и готов инвестировать время, внимание и энергию в изучение нового. Если говорить о прикладной области бизнеса, для разных проектов может потребоваться совершенно разная степень вовлечения и понимания сути процессов на стороне клиента. В этом, на самом деле, нет ничего нового. Можно вспомнить наше базовое образование, скажем, прикладную кибернетику — соответствующий факультет, например, в Киеве оканчивали очень многие. Куда уходят ребята, получив в дипломе квалификацию математика? Кто-то к Антонову на авиазавод, где изучает аэродинамику и сопромат. Кто-то — к Амосову, учить биологию и анатомию. Кто-то — в банк, где знакомится с платежными системами и денежными потоками. Всегда предполагалось, что если ты не просто кодировщик, а именно программист, то обязательно должен знать предметную область. И постоянно искать, в какую сторону развиваться с точки зрения технологий. Дело тут не в знании двух, трех, пяти языков программирования, подходов или методологий. Универсальность — в первую очередь, способность учиться непрерывно.

Например, у нас в DataArt есть направление изучения искусственного интеллекта. Это открытая группа, куда приходят люди из разных индустриальных практик и с разным профессиональным бэкграундом, чтобы обсудить, как ИИ можно было бы применить там, где они работают. Даже если прямо сейчас с искусственным интеллектом их направление дела не имеет. Но такое расширение знаний позволяет в перспективе«think out of the box».

Если человек выбрал направление и попал в большой проект, где собирается провести достаточно долгое время, прежде всего имеет смысл смотреть на технологии, которые могли бы пригодиться в этом проекте. Но любой проект рано или поздно заканчивается, и задавать себе вопрос «Чем бы я хотел заниматься после него?» очень полезно.

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

Обучение — не трата времени, а инвестиция в чистом виде. Именно поэтому всегда есть риск, что инвестиция не окупится, но если не делать вложений, развитие точно остановится, и на дивиденды рассчитывать не придется. Конечно, приходится смотреть на рынок и его тренды, а также, по возможности, диверсифицировать инвестиционный пакет, чтобы снизить риски. Но жизненная ситуация часто сама подсказывает, в каком направлении двигаться. Реальная свежая история: один из наших фронтенд-разработчиков недавно занялся бэкендом, и через три-четыре месяца получил приглашение в проект как фулстек со значительным повышением зарплаты. Но поскольку он параллельно уделял много времени командной работе и наведению порядке в проекте (ему было не все равно!), еще через полгода ему предложили стать тимлидом. Удобно, что в наше время, когда IT настолько востребованы, что бы ты ни изучал, предложения найдут тебя сами. Только не останавливайся.

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

Кстати, мне не нравится часто используемый термин «переобучение». Как будто прежние знания куда-то подевались, затерлись, и на их место были записаны новые. Это в корне неверно: для универсала экспертиза каждый раз расширяется, и накопленный опыт работает на будущее. Поэтому более подходящим будет применительно к IT использовать слово «дообучение». При этом никто не мешает углублять знания, прежде всего, по основной специальности: особенно круто выглядят коллеги, признанные экспертами в своей области, которые при этом легко могут говорить со специалистами смежных специальностей и немало знают об их работе. Пусть и не так глубоко погружены в предмет, как в случае с собственной основной специализацией.

Проверить себя

Прежде всего, чтобы разобраться с новой технологией, нужно решить с ее использованием какую-то реальную задачу. Это может быть работа в проекте под присмотром профильного специалиста, пет-проект или даже практическое задание в рамках курса. Что касается спектра интересов, могу предложить довольно простой калькулятор. Посмотри, что ты изучал в последнее время, какие книги и статьи читал. Сейчас очень многие материалы тегируются, собери для себя набор тегов к тому, что привлекло внимание в последние шесть-восемь месяцев. Если наборов таких тегов более пяти, это очень неплохо.

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

Широкий кругозор, узкий профиль

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

Мастер —творец, он относится к своему творчеству с любовью. Его творчество приносит ему не только радость, но неразрешенные вопросы, мучительный поиск ответов.

Ремесленник —качественный исполнитель, он размеренно выполняет работу, которая ему нравится, доставляет удовольствие, но он не творит.

Именно мастера, а не ремесленники, способствовали развитию человечества во всех сферах деятельности во все времена.

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

Верите ли в универсальность вы? Или лучше иметь хорошее и стабильное ремесло? Возможно, кто-то открыл для себя третий путь?

Продолжение, начало тут. Планы А («найти работу лучше прежней») и Б («найти работу примерно как эта») не сработали, план В («найти работу со снижением зп») скрипит по швам, пора прорабатывать план Г. План Г... ну это очень Г. Выезд из страны. Украина? Франция? Мексика? Что с кошками с учетом отсутствия титров, без которых они невъездные? Вещи? Медстраховка? Билеты при покупке «на через неделю» тоже дорого стоят. Да еще и на пятерых-семерых...

Май

Олег бы вовсе не работал
Но к сожалению пожрать
Уже давно не падал с неба
А ещё дети и жена
© не моё

Итак, сроки жмут, подаюсь везде. Хотя уже есть понимание, что тут скорее сработают компании с апреля, а майские просто не успеют. Так что подачу новых почти остановил, отвечаю рекрутерам.

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

На двух собеседованиях спросили: «Если вы программист, то какого Х вы учились в университете радиоэлектроники?». Ппц, это 20+ лет назад. Хорошо хоть его из горного успели переименовать. Вот это канадцам глубоко не понятно. Университет — значит университет. А то, что там учат не специальность, а учится учиться... Ну назвали бы тогда не «радиоэлектроники», а «общеполезных навыков», что ли. А особенности (пост)советского обучения их не гребут.

В новостях — погромы, «США вот-вот развалятся», с детства помню эту накачку. В Монреале тоже были беспорядки. Полиция даже один баллончик газа применила. Все очень вежливые и доброжелательные, даже когда интересы конфликтуют.

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

В машине сгорел аккумулятор, обсуждаем с женой покупку нового. А может, как-то старый можно реанимировать? Если машину через пару недель продаем, зачем туда новый покупать?

«Самый страшный зверь на дороге — школьный автобус», — слышали такое про Америку? Если он откинул стоп-сигнал, то нужно замереть и не шевелиться. Так вот, есть компания BusPatrol, которая бесплатно ставит камеры на автобусы и живет с процента на штрафы. Хорошо живет. Впрочем, второй раз люди уже не попадаются. Кстати, еще одна демонстрация, что ключевую роль играет не размер штрафа, а неизбежность его применения.

Одна очень крупная компания в вакансии желала, чтобы кандидат читал код зависимостей. Сильный ход с учетом их числа даже в маленьком проекте. А еще они занимались рекламой, что совсем противоречит области, где я бы хотел работать. Но, к сожалению, «пожрать» уже давно не падал с неба... Подался, серия собесов, два тестовых, отказ.

Нервничаю. Особенно меня выбивает игнорирование: я вкладывался, писал письма, проходил собесы, делал тестовые, а в ответ либо тишина, либо шаблонный отказ. Это делает меня еще тревожнее, да и тяга к катастрофизации помогает волноваться сильнее. Счет идет на дни. Каждые пять минут проверяю почту. Расчесываю себя в кровь, и это не преувеличение, нейродермит — родственник астмы. Помогает дыхательная медитация по квадрату, но всё же. Сил на велосипед просто нет. Давление растет.

Вот эта фотография за середину мая. Я ее выставил у себя в FB. Так вот, по фотке никто не заметил депрессии и тревожности. Еще раз — у человека может быть депрессия и он может вполне улыбаться и дурачиться. Одно другому не особо мешает.

Есть вариант податься на любую визу, чтобы получить implied statusи не нарушать визовое законодательство. Но это очень на грани. Можно еще поменять на visitor record, но в нем я просто обязан покинуть страну для подачи на следующую визу, даже если найду работу. Ага, с кошками, вещами, арендой дома и авиаперелетом в ковид-эпоху.

Когда-то давно Дмитрий Снисарьменя научил приему. Делается, как только отловил в голове обсасывание какой-то затертой мысли. Ну например: «Что мы будем делать с кошками?», «Где мы будем жить?», «А денег-то на сколько хватит?», «Ты неудачник и никому не нужен», «Сколько можно рассылать резюме? Безнадежно это»... Обычно от обдумывания по трехсотому разу одной и той же мысли без новых вводных пользы нет. А некоторые-то мысли и один раз лучше не думать. Так вот, как только ловишь себя на такой мысли, нужно подумать: «Спасибо, эта мысль не полезна мне сейчас». Именно в такой формулировке. По итогу я понаставил кучу триггеров в мозгу для отлавливания таких мыслей-паразитов.

Изучаем контейнеризацию. Не всё идеально.

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

В итоге при проверке в нем нашли несущественную опечатку в доке. И еще: «Н-у-у, тесты мы обычно организуем другим способом». Как я понял, это про тот самый баланс между DRY и читаемостью. По поводу пяти дней — там был стек для меня малознакомый. Знал бы я все технологии, наверно, дня за два-три можно было бы сделать.

Хорошая практика — гуглить текст задания после его выполнения, но перед сдачей, чтобы увидеть, не упустил ли что-то важное. Я нашел текст этого пятидневного задания на Upwork, его предлагали сделать за $35, и было много желающих. Так вот, если вдруг вы захотите фрилансить на Upwork и вам попадется дурацкое задание — возможно, это чьё-то тестовое на работу. Кстати, если делать это задание не «чтобы блестело», а «чтобы сдать», то и за день можно.

Заходили новые арендаторы, которые вселятся в дом после нашего отъезда. Приятные, хорошие люди, обсудили дефект-лист по дому и что из мебели/вещей мы готовы им продать. А мы еще даже не знаем, куда и когда выедем.

Привычка рекрутеров звонить задалбывает. В середине мая они как с цепи сорвались. Видать, рынок открылся, а они живут с процентов и сидели без зарплаты?

Нервничаем мы с женой, это передается детям. Когда дети чувствуют неуверенность и нервничают, они жмутся к родителям и требуют внимания. Завязка фильма «Один дома», где толпа детей конкурировала за внимание не на пустом месте возникла, держаться за родителей — это важный эволюционный фактор выживания. Но когда нервные дети жмутся к нервным родителям, то это много конфликтов и несправедливостей на ровном месте.

Написал мне еще один рекрутер, договорились о скрининге. Зашедулили в гугл-календаре, все дела. Незадолго до скрининга получаю автоматическое письмо: «Ваш скрининг перенесен на завтра на то же время». При этом меня не предупредили и не глянули, есть ли у меня там окно. Случайно окно было, ну ок. Через 15 минут после ожидаемого начала звонка рекрутер написал, что занят и предложил перенести на попозже. Ок, сдвинули на несколько часов. Через 10 минут после ожидаемого начала позвонил и сказал, что очень занят, и предложил перенести на вечер. Долго извинялся. О-о-к.

Вечером не позвонил, но позже прислал письмо, что перенес еще на день. Ну и какого?!

Естественно, не позвонил. У меня в это время было несколько компаний на финальных стадиях, так что ну его в болото, не до тебя.

Этот странный рекрутер позвонил мне через неделю, внезапно. Провел скрининг за семь минут, я засекал. Быстрее, чем извинялся за сорванный звонок. К этому моменту часть финальных компаний прислали отказы, так что я договорился о собесах.

Работать-то я буду совсем не с рекрутером. Дорогой Ванкувер, намного меньшая зарплата. В январе я бы поржал от такого предложения. Если всё сработает, то будем впятером жить, работать и учиться в двух- или трех-комнатной квартире. Плюс, наверное, машину гнать через 5000 км.

Очень быстрая серия собеседований за два дня. На одном из них на PDF с заданием на второй странице был чек-лист с подводными камнями этого задания. Впрочем, заметил я его слишком поздно. «Ребята, вы что?» — «Ы-ы, мы не привыкли к онлайн-формату». Прошел все этапы собеседований — оффер!!! Фух! Ура-ура-ура!

Бросаю то самое пятидневное тестовое со словами: «Вот есть to-do лист, к сожалению, не успеваю прикрутить к этой демке пул коннекшенов, да и по производительности еще вижу, где выжать можно процентов 20. Впрочем, это явно за рамками тестового». В ответ получаю: «Мы посмотрим чуть позже». Ну и ладно, с вами у меня шанс успеть был небольшой, конец мая всё-таки.

26 мая

Осталась неделя до финального срока. Если не успеем, то для подачи на визу нужно будет выехать из страны. С детьми и кошками, и поскольку непонятно, дадут ли визу, нужно что-то делать с вещами. Везти с собой? Продавать? Арендовать склад? А что если не сможем вернуться? Решение следует принять сейчас, данных нет. Счет уже идет скорее на часы, чем на дни.

Чтобы остаться, нужно податься на визу. Чтобы податься, нужно LMIA, это такое разрешение для компании нанять иностранца с пользой для экономики и рынка труда. Дается, если есть доказательство, что они пробовали нанять туда канадца и не смогли. Для LMIA и оффера нужен HR, но она после тяжелой автоаварии несколько месяцев назад еще не вполне вернулась в строй и часто в больнице на процедурах. Контракт мне так и не прислали, и вообще за время беготни с бумагами его условия поменялись: «Мы думали тебя оформить как контрактора, но из-за визы не получается, давай оформим как постоянного сотрудника, но зп еще меньше». Примерно в полтора раза меньше той, которая у меня была.

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

Напряжение растет. Думаю, что мы держимся во многом благодаря тренингам по Синтон-программе, особенно выездным лагерям и «трудным играм», которые прошли лет этак двадцать назад. Ну и КПТ-психотерапии, да. Понятия не имею, что сейчас с Синтоном и Козловым, зато хочу сказать спасибо Елене Неводничей, Анне Лебедевой,Владимиру Станчишинуи Диме Снисарю. И да, в русскоязычном инфопространстве принято хаять тренинги личностного роста. Не скажу за остальные, а вот эти точно мне пригодились. И благодаря им наша семья не распалась на многочисленных поворотах.

28 мая

Вместе с HR долбим систему подачи на визу:

• без кода LMIA форма не проходит валидацию;
• у них нет LMIA на менеджера, только на программиста;
• на программиста мне подаваться лучше не надо, «ты в Канаду как менеджер заехал, будет долго и не факт, что получится»;
• как менеджер — «у нас вакансия висит недавно, мы не успеем сделать LMIA»;
• пробуем на BC PNP, это сразу вид на жительство. По словам HR, оно обычно срабатывает автоматически на первый этап, что дает возможность всё подготовить, но тут бы неделю запаса. Для подачи анкеты нужно ввести результат IELTS. Я сдавал 2018-05-12,действует два года. Система не принимает дату «12 мая»;
• HR внезапно вспоминает, что тест считается не по дате сдачи, а по дате проверки. Смотрю. 24 мая! 24-е!!!Сегодня 28-е,не годится;
• новый тест был оплачен на 3 мая, но из-за локдауна перенесен на 20 июня. Да и после года в Канаде я вряд ли ухудшил свои старые показатели. Это легко объяснить человеку, но не пускает-то робот. Код результата теста устарел — до свидания, кожаный мешок;
• смотрим вакансии соседних отделов в той же компании. Находим позицию Program Manager. Служебные обязанности — как под меня написаны. HR нужно поговорить с директором об этом.

29 мая

Пятница. Уже пора выяснять, виза действует до вечера или до утра понедельника. HR в больнице, связи с ней нет, текста контракта нет, зато есть идея, как прорваться через вакансию Program Manager. Звонок из компании, в которую я делал то пятидневное тестовое. Второй оффер! Ура-ура-ура! Они понимают, что я спешу, и изо всех сил пытаются ускорить процесс. Для компании 1000+ это нетривиально.

В итоге на руках два оффера:

1. Ванкувер, русскоязычная компания, богатый опыт борьбы с визами, хороший шанс получить вид на жительство еще в этом году. Из пяти человек, с кем я общался, бизнес-эффективным был только директор. Остальные как-то хаотично себя вели. Переезд через континент, детям «выбрось всё, чему год учился, начинай новый язык», зарплата в примерно полтора раза ниже, сильное падение уровня жизни. Скорее всего, временное, но всё равно. Ну и поездки в Харьков из Ванкувера еще сложнее — дольше, дороже, больше пересадок. И оффер я уже принял на словах, хотя бумаг и условий еще не видел.

2. Монреаль, компания из США, только открывают R&D-офис здесь, что явно плюс для меня в перспективе. Компания ближе мне по духу, но у них нет опыта с визами, вид на жительство — через годы. Зарплата... как нынешняя плюс страховка. Монреаль нравится.

По обоим офферам — не факт, что успеем. Мне нужно время! Неделя хотя бы. Я начал подготовку к новой визе за пять месяцев до, и вот недели не хватает! Хотя сделал вроде всё. Пишу письмо на старую работу с вопросом: а можем ли мы податься на продление визы, а пока там будут обдумывать — у меня будет оффер от новой компании? За подробностями — гуглить implied status.

Обзваниваю друзей, советуюсь, думаю, обсуждаем в семейном кругу. Со старой работы приходит отказ. То есть меня любят, ценят, но брать даже фейковые обязательства на себя не могут. Принимаю оффер номер два. Это BusPatrol, так что, если вы хотите тайно передать мне денег, попробуйте проехать мимо школьного автобуса, когда он выпустил стоп-сигнал.

Созваниваюсь с компанией в Ванкувере, извиняюсь. Директор, кажется, немного ах... ээээ... озадачен эффективностью процесса найма и задает пару вопросов. Он был уверен, что оффер я уже подписал. Текста предложения мне так и не прислали.

Серия звонков с BusPatrol, мы явно не успеваем разобраться во всех деталях. Я подключаю Клаудиоса, плачу 1356 CAD госкомиссии + 860 CAD Клаудиосу за работу. Начинается мучительный период «Ждём-ждём-ждём, а-а-а! Срочно пришли вот это! Ждём-ждём-ждём — внезапный конференц-колл по телефону с Клаудиосом и двумя директорами. Ждём-ждём-ждём».

В ночь с первого на второе июня, за несколько часов до дедлайна, Клаудиос успевает подать документы. Фух? Нет! В документах не всё гладко, так что это только конец первого сезона, продолжение следует.

Одно хорошо, скоро это всё закончится. Должны дать ответ, как понимаю, за десять бизнес-дней.

Попыток 35, скринингов 9, циклов собесов 4.

Спин-офф: корпкультура

Разговаривал с менеджером одной очень крупной ІТ-компании. Из тех, которые часто в новостях. Из тех, в которые хотят многие программисты. И зашел разговор про внутренние тренинги для менеджеров и их тематику.

Так вот, на работе нужно работать. Только работать. Ничего больше, кроме как работать.

Шутки нужно подбирать тщательно: они могут быть оскорбительными для кого-то. Поэтому лучше не шутить.

Никаких комплиментов за исключением выполненной работы.

Никаких встреч в непросматриваемых помещениях и флирта. Иначе есть шанс доказывать в суде, что ты никакого харрасмента в виду не имел, а просто пошутил о раскрытии неопределенностей методом Лопиталя.

Чужие шутки тоже нужно отслеживать.

Исключительная осторожность в фидбеке, иначе есть шанс доказывать в суде, почему ты считаешь, что не справляется с должностными обязанностями, а ведь хорошее образование и отзывы.

И всё это с подробными описаниями реальных случаев.

Я хз, как это сказывается на командном духе, могу только догадываться.

Буду думать.

Июнь

«Если вы проходите через ад — продолжайте идти» © не моё

2 июня

Итак, мы подали документы. Но в документах есть два маленьких недостатка. С моей стороны просрочен IELTS, но это терпимо. Со стороны компании — они только-только открыли R&D в Монреале, и там бумаги будут через неделю. Поэтому мы отправили заявку из расчета, что, пока ее будут ждать в очереди, мы подготовим всё необходимое и подсунем под скрепочку. То есть всё очень на грани, и если вдруг они отпроцессят раньше, то визу могут зарубить, а для подачи на следующую нужно выехать из страны. Кошки, вещи, аренда, билеты, все дела.

3 июня

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

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

Продолжаю собеседования с теми компаниями, с которыми начал в мае. Опыт лишним не будет, я их предупреждал, что времени мало и что я на последних стадиях переговоров с другой компанией. А тут, если вдруг всё сорвется, будет еще один задел на будущее.

Друзья спрашивают про отпуск, предлагают покататься по Канаде. Ага, отпуск. В условиях неопределенности. Щаз. Планирование как в шахматах? Мат!

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

Решил написать пет-проект. Поскольку у меня есть всего пара дней, пишу максимально грязный код. Вот никогда не писал настолько плохо, а тут «можно сэкономить 15 секунд при наборе? Нужно!» Зачем так? Иногда стоит делать всё максимально неправильно. И это правильно делать, когда ты в безопасной песочнице.

Кошкам таки сделали прививку от бешенства. На всякий случай. Между прививкой и титрами, если они понадобятся, должно пройти несколько недель.

10 июня

Air France сообщает, что наполовину отменен мой старый билет Монреаль-Париж-Киев на сентябрь. Вот Монреаль-Париж лети, а дальше — пешком. Могу вернуть деньги. По умолчанию деньги вернут на ту же карточку, с которой куплены билеты. Ага, в том банке я уже давно закрыл счет. К счастью, это можно отложить до августа.

Из внезапных задач: а собери-ка ты отзывы на себя со всех предыдущих мест работы за 10 лет. Э-э-э.... ладно с последнего — там подпишут всё что угодно, с предпоследнего — это мой бизнес, кого я там спрашивать-то буду? Кстати, тут вполне могут позвонить на старую работу, поговорить с начальством.

16 июня

В очередной раз трясу Клаудиоса, и выясняется, что он ждет каких-то бумаг от компании. Трясу их, созваниваемся, там взаимонепонимание, на следующий день всё уже ок.

Через две недели мы должны освободить дом. Уже давно пора договариваться про грузовик. Это не говоря уже про то, что хорошо бы знать, куда мы будем выезжать. А визу могут и не дать! От новых арендаторов узнаем, что они въедут 4 августа. Пишу лендлорду: «У вас дом простаивает, а давайте мы у вас еще несколько недель поживем на прежних условиях? Готовы заплатить вперед». После нескольких туда-сюда и недели времени удалось договориться до 20 июля. Фух! Одна проблема отодвинулась! Отменяю отключение интернета с 1 июля, выдыхаем.

18 июня

В США продолжаются погромы. Я из окна машины видел, как загорелый парень забивал лежачего полицейского огромной кувалдой. Оказывается, иногда «лежачий полицейский» крепится к полотну дороги именно с помощью кувалды. «Лежачий полицейский» — это такая кочка на дороге, чтобы не гоняли.

Выясняется, что я неправильно понял письмо и кое-какие подписи нужны в бумажных оригиналах. Скок в машину, сделали.

Через какое-то время все бумаги были поданы во все инстанции. Вот насколько Клаудиос был общительным и помогающим до заключения контракта, так стал очень расплывчатым про этапы и сроки после заключения. И, как мне кажется, явно переориентировался с меня на компанию-нанимателя. Ну, это понятно: я ему как максимум еще пару дел принесу, а компания может через него еще много людей прогнать. В общем, всё общение стало пусть и быстрым, но невероятно уклончивым. Его можно понять, он не может давать обещаний за то, что не контролирует. А нюансы этапов — это профессиональные секреты. С другой стороны, мне от этого не легче.

На иммиграционном сайте написано, что 80% всех заявок обрабатывается за 10 бизнес-дней. Прошло три недели — ответа нет. Боюсь, что если будут какие-то сложности с визой и придется выезжать и переподаваться, то компания на меня забьет.

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

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

30 июня

От Клаудиоса и иммиграционных властей ничего, но от компании получаю письмо, что выход на работу будет не 1 июля, а 6-го.Шта? Откуда вообще взялись эти даты? Откуда вы это знаете? В любом случае — воодушевлен, начинаем активничать с выбором дома. Вот вроде ничего не поменялось, а воодушевление есть. Хотя и нервничаем.

Одно хорошо, скоро это всё закончится и начнется нормальная обычная работа. Скучные глюки с регэкспом, устаревшие библиотеки и занудное разглаживание легаси. В конце концов, ответственность только за себя и свой маленький кусочек.

Спин-офф: как мне повезло, что я айтишник

Вот щас подумал, как мне повезло с айтишной работой.

Без компьютера сложно стать айтишником. Чтобы у меня появился мой первый компьютер (ZX) в ~1989, родители продали дачу. Компьютер, конечно, не был основной причиной продажи, но без продажи дачи это было просто невозможно. Следующий компьютер, жутко устаревшую 386, удалось купить уже в 1999-м,как раз когда я ХИРЭ заканчивал.

В общем, чтобы найти где-то компьютерное время, мне приходилось:

• идти на курсы войтивайтишников. Там не давали теорию, но давали короткое задание, а потом бегло проверяли результат. Большое спасибо МИИК-Валидио-Глобалу за это;
• выпрашивать компы у всех подряд. Представьте, что вы начинающий водитель и вам сейчас нужно у кого-то выпросить новенький внедорожник. Несколько раз в неделю, у разных людей. И если вы его вдруг разобьете, то отдавать будет просто не с чего. Хоть квартиру продавай;
• ездить к папиному другу через пол города;
• прогуливать пары, чтобы пойти к знакомому, у которого на работе иногда компы простаивали;
• позже — воевать с лаборантками со всем их комплексом «маленький начальник».

Еще стоит сказать пару слов про обучение. В самые голодные 1992-93родители нашли деньги на моё обучение в лицее при ХИРЭ. «Выхожу из дому утром — в холодильнике пусто. Что заработаю — смогу купить что-то на ужин детям» — из воспоминаний мамы. Нам буквально было нечего есть, но я ходил на занятия по математике, физике, украинскому языку и истории. Ну и на формально 3, а фактически 9 часов в неделю на компе, до которого я ехал полтора часа в одну сторону. Лицей дал возможность поступить на профильную специальность без конкурса, а по конкурсу там даже медалистов-олимпиадников не брали, только блатных.

Мы надеялись, что в ХИРЭ будет с компьютерами попроще... Ну, часа 4 было формально, а еще часов 10 я набивал всякими левыми путями. Кстати, на самой айтишной специальности самого айтишного вуза второго по величине городе страны айтишным дисциплинам уделялось менее 10% времени, а если считать качество — так менее 2%. Остальное время нас «учили учиться» и прочим «основам безопасности жизнедеятельности при работе с ПК». Кто хочет с этим спорить — достанем вкладыш от диплома и подсчитаем часы.

Интернета у нас еще не было, книги стоили совершенно недоступных мне денег — каждая около месячного семейного бюджета. Поэтому я зависал в библиотеках, пытаясь хоть что-то вынести. Читаешь книжку на 800 страниц по новому для себя языку программирования, ксерить дорого — делаешь выписки. Через день-другой на чужом компе пытаешься что-то написать. Я тогда невероятно бурно учился. Никакой личной жизни, гулянок и прочего. Вместо этого непрерывное метание между предметами, без которых выгонят, типа «История Украины» и «Физкультура», и важным выбором «пойти на пару по интересной теории формальных систем либо пойти в лабораторию писать код?». Непрерывная учеба до физического отрубания. Самоизоляция от общества, проблемы в отношениях.

Да, в моей жизни было три случая, когда мне повезло. Первый раз — когда я выбрал между «Прикладной математикой» и «Программным обеспечением» второе, там хоть какие-то предметы по IT были. Второй — когда на первую работу меня взяли по знакомству через третьи руки. И, самый важный, нулевой — когда родители поддержали меня в моем выборе. Тогда направление IT совсем не выглядело перспективным.

Потом было много чего: смена языков, ролей, профессий, свой бизнес, взлеты и падения. Жесткая работа над своим поведением и реакциями в группе прикладной психологии Синтона и два курса психотерапии, которые как минимум удвоили мой доход за счет повышения эффективности.

А так да, конечно, теперь мне повезло, что я айтишник.

И еще нужно упомянуть, что мой способ убегания от проблем — это компьютерные игры. И заметное время я тратил-таки на убегание в них.

Июль

«Фраза „выйти на новую работу“ в 2020 году означает, не меняя положения в кресле, перелогиниться в Slack’e» © не моё

1 июля

Утро начинается со звонка в дверь. Там стоит улыбчивый мужик в комбинезоне и сквозь дверь как-то странно поглядывает на наши вещи. Спрашивает, во сколько выедем, чтобы они начали ремонт. Объясняю, что с его начальством я уже давно договорился и что никуда мы не едем. Удивляется, обещает вернуться «если что», уходит.

Ищем дом. Просматриваем массу вариантов.

2 июля

Видел парикмахера, у него от локтя был протез с насадками для стрижки. На «Хабре» статьи про слепых программистов. Молодцы.

3 июля

Весь день доказывал, что я сильный программист. В смысле друзья переезжали, и я помогал вещи таскать. Устал, приехал домой с мыслью «успею поесть и в душ или сразу отпаду спать?». И выиграл бонус! Звонок от другого друга-соседа: «Мы на вылазке, а нам внезапно привезли дорогой стол и по канадской традиции бросили под дверью. Если можешь, закинь его в гараж».

7 июля

Клаудиос отвечает уклончиво и скорее устно, чем письменно. Всё время ссылается, что с ковидом все стало сложнее и медленнее. Мне охренительно не нравится, что у меня нет доступа к моему иммиграционному делу. Я могу получить этот доступ, но тогда Клаудиос его потеряет, так что не время. Сдерживаюсь.

Внезапно он звонит мне, и от моего имени составляем письмо на иммиграционную службу «а собственно, как дела?».

10 июля

Мне пишут из компании, что визу одобрили и что буквально завтра уже можно приступать. Ура! Хотя почему это из компании, а не Клаудиос? Whiskey Tango Foxtrot?! WTF?

11 июля

Официального подтверждения нет, работать не просто не могу — работа сейчас вроде как это нарушение визового законодательства. Что запросто ведет к депортации и сложностям к въезду во многие другие страны. Зато могу уже заключать аренду. Наверное. Если подпишу, а визы не будет — это ой и новые приключения.

Получил ноут. То есть просто зашел в офис, представился и получил MacBook Pro. На фотке — стильная универсальная в своем дизайне вешалка. Они очень ей гордятся. Я видел такие и в деревне, и в офисах интернациональных корпораций.

Через неделю нужно освободить дом, и там уже нет возможности для маневра. Выбор дома — это отдельный лонгрид. «Я, риэлтор, подготавливаю для хозяина шорт-лист кандидатов с личными делами и проверенными референсами, письмами и так далее, а он выберет».

Пуша поймала и съела птичку. С клювом. Всю семью колбасит. Вроде и не вегетарианцы, знаем, что первый год своей жизни она провела на теплотрассе в лесу, а всё равно.

14 июля

Жена сменила пол.

С М на Ж.

Бесплатно.

В правах.

Кмк, в реале я бы заметил, с тремя-то совместными детьми.

В феврале получила права, дома увидели опечатку. Потом ковид и локдаун. И только сейчас получили исправление.

Местные говорят, что если кто-то бы прицепился к неправильному полу, то этот кто-то был бы должен нам денег. Пол — дело сугубо личное, и дорожной полиции не касается. Хоть два раза в день меняй.

16 июля

От Клаудиоса сообщение, что визу окончательно утвердили. Кстати, на визе стоит дата 10-е.На работу я выхожу в понедельник, 20-го.Как понимаю, Клаудиос всё делал через бумагу, а не через электронный формат. Если считать мою зп как 100к (NDA), то за выход на работу не 11-го,а 20-гоя потерял (100000/12) * (9/30) * (1 — 0.4 налоги) = 1500 CAD. Это если считать только время на передачу визы в эту сторону, наверняка нужно добавить и время на отправку бумажных документов, и их медленный процессинг в ту сторону. А ему за работу я заплатил 860. То есть из моих затрат больше ушло на ожидание почты, чем на его услуги.

Важно! Без Клаудиоса вообще бы ничего не вышло с учетом тех сроков и обстоятельств. Так что чувства у меня амбивалентные. И еще, такое впечатление, что все иммиграционные консультанты имеют специализацию. Все предыдущие, с кем я говорил, были заточены на «а давайте студентом в вуз», а Клаудиос умеет в Global Talent Stream — это такая программа, которая позволяет быстро нанимать иностранцев. Быстро — это в том случае, когда у компании уже готовы бумаги, а не как у меня. Ну и эта программа требует от компании довольно много обязательств типа нанять пачку канадцев, провести тренинги и так далее. То есть сильно связывает им руки. Спасибо им, что ради меня с этим связались.

Фух? Нет, впереди переезд и выход на работу. И вообще, все дела, которые мы с января откладывали, внезапно вышли из статуса blocked в статус «а-а-а, их нужно было сделать три месяца назад».

17 июля

В арендованных домах здесь чаще всего нет бытовой техники. Так что срочно покупаем. Заказал онлайн, надпись «Спасибо за заказ, доставим 4 сентября!» заметил в последний момент. Ага, полтора месяца лета без холодильника, стиралки и плиты. Спасибо, отмена. Выезд по супермаркетам, купили.

Я отвык от таких скоростей. «Розетка» разбаловала. И еще мне не хватает сравнения товаров с «Розетки» и Hotline, например, чтобы сравнить роутеры MikroTik и Google и какой-то Netgear.

18 июля

Переездец. Арендовали Uhaul, это грузовик, который можно водить по правам от легковушки. Теперь мы от таких на дорогах стараемся держаться подальше — там за рулем наверняка кто-то без опыта вождения больших машин. 140 CAD за день со всеми тележками. Спасибо друзьям, помогли таскать и водить.

19 июля, воскресенье, 6 утра

Третий, самый дальний туалет в доме: «Папа, включи мне планшетку». Ппц.

Холодильник издает странные звуки. Что-то похожее издают кошки во сне. Полумяуканье, полувсхлипы тихонькие. Может, у него так пищеварение работает? В инструкции большими буквами написано, что это нормально.

20 июля

Вышел на работу. Дом в коробочках, быт не устаканен, зато есть куча кода, в который можно закопаться. Фух! Отпуск окончен, хватит отдыхать и расслабляться, пора работать!

Скучная статистика

Этапы:

1. Подался всего 188 раз.
2. Скрининг 52 + отказы по резюме 19 + тишина 117 = 188.
3. Циклов собеседований и тестовых 16 + отказы по скринингу 23 + тишина 13 = 52.
4. Оффера 2 + отказы по собеседованию 12 + тишина 2 = 16.

Итого конверсия около 1%. У войтивайтишников похожая, поддерживайте их.

Особые случаи я стандартизировал, тестовые задания приравнивал к собеседованию и применял другие способы нормализации с потерей точности. Тех, кто отвечал дольше месяца, относил к молчунам.

Общие выводы

«Вы мало что можете сделать с длинной своей жизни, зато очень многое — с шириной» © не моё

Было ли тяжело? Было. Однозначно ударило и по нервам, и по здоровью. По сложности я бы сказал, что похоже на рождение ребенка. Очень сложно было сохранить самооценку, а без реалистичной самооценки на собеседовании делать нефиг.

Было ли тревожно? Да, не то слово. Для меня тревожность вообще характерна, как понимаю, это особенности детства. Гуглить по словам «амигдала» и CBT. Лучше на английском и посвежее. Вообще, скорее всего, я буду жить с тревожностью всегда. Самое лучшее, что я могу сделать — это отслеживать ее проявления и тормозить ложные срабатывания. И самое главное — передать детям более адаптивные паттерны поведения.

Как мы это пережили? И у меня, и у жены, и у вас есть дохера травм из детства. Еще больше таких травм было у прошлого поколения. А у позапрошлого — так вообще. Мы с женой познакомились в Синтоне, где упор был на осознанность. И мы не даем друг другу сваливаться в автоматическое поведение слишком часто или слишком сильно.

Хотел бы я еще раз такое? Нет, спасибо. Я лучше стану сильнее другим способом. Но и бегать от рисков зря тоже не буду. «Хорошо защищенный от взлома компьютер — это выключенный из сети в цельном железобетонном кубе глубоко под землей. Всё остальное — компромиссы» © не моё

Все ли переехавшие проходят через такое? Скорее всего, нет, это вероятностный процесс. Возраст плюс полуменеджерское-полупрограммистское резюме плюс большая семья умножить на мировой кризис.

Была ли какая-то канадская специфика? Не похоже. Просто сошлось несколько факторов, и ага. Мог ли я выгрести так дома? Да не то слово. Выгребал, жизнь у меня бурная. Только прессинг был не из-за визы, а из-за денег. Точно можно написать года этак с 2007-го,что я делал свою жизнь очень бурной. 1999-2000тоже да. Пожалуй, был тихий период с 2001 по 2007-й,про него просто не помню: там только рост до сеньора, первая менеджерская позиция, первый ребенок и переезд с месячным ребенком на руках в квартиру «без ремонта».

Вообще, часто что-то тяжелое приходит без связи с действиями/бездействиями: война, болезни, мировые кризисы. Вопрос в скорости адаптации и конструктивности действий. И да, иногда идея «сквозь щель в полу ползущего товарняка выпихиваю семилетнего ребенка одного в ночь на рельсы» — самая конструктивная. К счастью, мир становится в среднем лучше. И того ужаса, который пережили наши предки, нам просто не достается.

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

Кем я вижу себя через пять лет? Думаю, что опять стану менеджером. Вот прямо сейчас мне кажется, что для меня идеальная работа — это общаться с нетехническим продакт-оунером в Канаде и управлять технической командой в Украине. Пока что это невозможно, но через несколько лет — вполне. Я умею слушать и говорить и на языке бизнеса, и на языке программистов.

Спин-офф. Году этак в 2010-мобщался я с коллегой, и зашла речь о планах на жизнь. Он сказал: «Я простой деревенский парень, для меня переехать в город и, тем более, стать программистом — это невероятное достижение. Я не хочу и не планирую становиться тимлидом или менеджером». Недавно мы с ним опять обменялись парой слов. Как понял, он давно стал менеджером и вернулся в Украину после нескольких лет жизни в других странах. Вернулся со словами, что ему там не понравилось. Это нормально — менять планы и цели.

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

Скучаю ли я по Украине? Скучаю по отдельным людям, а не по стране. Тут как дома, которого у меня не было. Из-за людей, все очень вежливые, неагрессивные и помогающие. Хотя и границы блюдут.

Я чувствую себя здесь своим. Мне нравится дружелюбие монреальцев. За год я влипал в несколько бытовых конфликтов: сильно попал девушке рукой по лицу, дважды заехал на веле куда нельзя, запарковались неудачно в гараже, заблокировал велосипедом автобус, тупил на кассе и в очереди, товар возвращали и так далее. Здесь люди конфликтуют и отстаивают свои границы, но при этом всё очень мягко и комфортно. Если в Харькове мне нужно было вкладываться, чтобы не влипнуть в конфликты с соседями, то тут это легко. Впрочем, проблемные люди тоже есть, просто намного реже. Можно глянуть вот этот ролик — очень канадский подход по работе с агрессивными пришельцами.

В Украине одинокий здоровый сеньор живет гораздо лучше, чем в Канаде. Если у вас единственный критерий «сколько остается после обязательных трат» — Канада плохой выбор. Вообще, если вы не знаете, зачем переезжать — вам это и не надо. Наши причины я изложил в «Канада для ІТ-шника».

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

Переезд:

• Кризисы мировые бывают каждые лет 10. Плюс еще локальные, так что лет 8 в среднем. Иногда в них влетаешь очень здорово. Если бы не локдаун, эта вся история закончилась бы банально в апреле без экстрима. Если бы у меня был вид на жительство, сидел бы на пособии и лениво перебирал вакансии. А тут локдаун, резюме «не очень» и поджимающая виза. Вычеркните любой из компонентов — драматизма будет меньше. Добавьте «енот украл паспорт, а виза привязана к паспорту» — будет больше. Добавьте «скунс пометил папку с документами» — будет юморнее.
• Если хотите переехать спокойно, едьте как программист/DevOps/QA/BA в компанию среднего размера. Выбирайте работу заранее в хорошо известной области.
• Опять же, если бы мы решили переехать десять лет назад, то возраст бы позволил получить вид на жительство без возни с трудовой визой и приглашений на работу было бы куда больше.
• Всё было бы намного сложнее, если бы у нас не было финансовой подушки безопасности. Когда мы входили в эту историю, всё выглядело гладко, а только потом начало закручиваться.
• Полтора года назад сходить в отпуск, пока ждали ответа на визу — это была отличная идея.

Шансы:

• Менеджерам в десятки раз сложнее, чем программистам, как и в Украине. Хотя бы потому, что менеджеров надо меньше, еще и местная специфика. Например, фонд оплаты труда совсем не похож, тут есть куча налогов и соцнагрузки. Или увольнение, которое может быть очень сложным для работодателя. Особенно если увольняемый долго проработал и уходить не хочет. Опять же, менеджерские зарплаты тут выше, значит, выше и престиж, и конкуренция.
• Теоретически менеджеры должны лучше понимать подход «переезд как проект», с WBS и «ищу решения, а не преграды». Практически маленькую вероятность найма можно обойти двумя способами: или числом попыток, или перепрофилированием на базовую специальность. Например, вы же менеджером не сразу стали? Обновите навыки, подточите резюме. Перечитайте начало моей истории: и как у программиста, и как у менеджера у меня была масса недостатков. В личной жизни та же система: при неидеальных исходных ты или улучшаешь то, что есть, или берешь количеством. У войтивайтишников — та же система, ты бегаешь по собеседованиям и параллельно учишься.
• Еще раз, статистика работает на большом количестве попыток. Мне понадобилось две сотни попыток до получения результата. Я их уложил в пять месяцев. Если делать одну попытку в неделю, то при тех же исходных уйдет четыре года. Если одну в месяц, то вообще никогда. А если у вас востребованная специализация, вам 30, 7 лет стажа в двух компаниях по профилю после профильного вуза, идеальный английский — так и одной попытки может хватить.
• Много людей сдаются после пары провалов. Часть продолжает одинаковые попытки, не меняя ничего. Или, что я вижу еще чаще, ставит недостижимые промежуточные цели типа «меня не взяли из-за английского, следующую попытку сделаю, когда подтяну с А2 до С1». Это несколько лет, да за это время основной предмет забудется!

Деньги:

• Запрошенная зарплата, пока она в вилке, на результат собеседований особо не влияла. Я помню только один или два отказа в самом начале, где сказали «не, это для нас много». Рынок труда важнее.
• Здесь рост зарплаты сопоставим с инфляцией. Очень мало шансов получить +20% за год на одном месте.
• Ваша старая зп часто видна бухгалтерам на новой работе. То есть при трудоустройстве сказать «у меня сейчас 100, поэтому хочу 120», а на самом деле было 80 — потом может быть неудобно. Опытные люди говорят, что правильнее свою нынешнюю зарплату вообще не называть. «У меня NDA, готов с вами работать за NNN».
• Разница между джуном и сеньором в зарплате — примерно вдвое. И так почти во всех профессиях. Это совсем не похоже на украинский мейнстрим «400 на старте, 1000 через год, от 2000 до 5000 через пять-десять лет». Тут «60к cad в год на старте, 90-120через десять лет». Числа примерны. Менеджеры могут получать больше.

Резюме:

• Похоже, тут почти все пользуются автоматическими парсилками резюме. Так что строго doc, никакого новомодного docx/pdf. И без красивого форматирования, которое нравится людям и прячет суть от роботов.
• И для робота, и для джун-рекрутера нормально не понимать контекста. «Вы написали, что пять лет на Rails, а на Ruby хоть какой-то опыт есть? А хоть что-то для бэкенда писали?», «Т-а-а-к, MySQL/Postgres/MSSQL/Mongo есть... А с базами вообще работали?» Это реальные вопросы.
• Каждый знает, как писать резюме. Есть даже специализированные фирмы по написанию резюме. Я тоже знаю, как писать резюме, так что к ним не пошел. Возможно, зря.

Общее:

• Некоторые компании делают бэкграунд-чек. Как я понимаю, на практике это сводится к быстрому просмотру профилей в соцсетях и поисках в базе правонарушителей. Но могут и обзвонить экс-коллег.
• Каждый пятый рекрутер шлет письмо и тут же звонит.
• Когда так дофига заявок, то нужны записи, с кем, о чем, на каком этапе и какое резюме посылал. И какую зп просил.
• Самая лучшая информация — через инсайдера. Но инсайдер, который даст тебе такую инфу, жестко нарушит NDA и может вылететь с работы в один день.
• Про JOIN’ы и «interface vs abstract classes» — только в русскоязычных компаниях спрашивали. В англоязычных — больше простейшие «напишите класс для кэширования» и про архитектуру/очереди/high-load. Даже если у них такой нагрузки и на горизонте нет.
• Про бирюзу нигде не слышал, а вот скрам и аджайл — три раза из четырех. Впрочем, по этим спрашивают чисто формально. Про теорию ограничений здесь похоже вообще не слышали.
• Для канадских компаний, похоже, важна скромность и отсутствие эго. Я этого пока не понял, я явно действую в американской парадигме, где нужно себя продавать.

Стоило ли оно того? Для нас — да.

Будет ли продолжение? Этот сезон окончен, я жив, а значит, что-то еще точно произойдет. Школа, медицина, жильё — там можно новые серии писать раз в неделю.

P.S. Многие предлагают сделать книгу/фильм на этой базе. Я точно не буду мощно в это вкладываться, и если вдруг кто-то чувствует желание, то можем поговорить. И еще, я подумываю переводить часть своих текстов на английский, а у меня там совсем нулевые аккаунты. Если тебе понравилось, что я пишу, и ты готов помочь лайком/репостом на англоязычном FB/LinkedIn/medium/reddit/etc — напиши мне в личку плз.

[Об авторе: Михаил Завилейский — Organisational Architect в DataArt. До прихода в компанию 10 лет работал программистом и менеджером]

В статье хочу привлечь внимание к качеству, которое называется «accountability» (можно перевести как «ответственность и подотчетность»). Прокачка аккаунтабилити повышает шансы, что вам доверят распоряжаться тем, что вам не принадлежит: активами, бюджетами, отношениями и временем коллег. То есть всем, что создает для профессионала рычаг и помогает в разы увеличивать масштаб свершений, и не ценой работы по 25 часов в сутки.

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

Любому профессионалу для реализации, помимо технических знаний, хотя бы на минимальном «гигиеническом» уровне нужны навыки сотрудничества (cooperation), умение решать проблемы (problem solving) и аккаунтабилити. Анализ собственного развития на каждом из этих направлений поможет в том числе определить вектор дальнейшего роста. Высокие показатели хотя бы в одной из областей открывают двери к экспертизе и консультированию, развитию и администрированию бизнеса.

Аккаунтабилити здесь теснее всего пересекается с администрированием, но определенный уровень нужен всем, кто хотя бы время от времени контактирует с клиентами. Сама же концепция из трех перечисленных навыков интуитивно наименее понятна, что и побудило меня написать этот текст.

Иллюстрация Ульяны Патоки

Введение

(лирика, которую можно опустить тем, кто не любит «размышления на тему»)

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

Чтобы с нами было удобно работать, у коллег (эх, нет хорошего перевода слова cooperator/collaborator) не должно возникать проблем с нашей адекватностью, предсказуемостью и управляемостью... По крайней мере, пока не придет полное к нам доверие. А до этого ответом на не до конца понятные действия будут попытки тотального контроля и микроменеджмента.

К сожалению, лучший ответ на вопрос «как же оставаться инициативным, самостоятельным и свободным в принятии решений и одновременно управляемым?» один — «помоги себе сам». Помощь извне оборачивается тем самым контролем и вождением за руку.

В английском слово accountability совмещает два значения: ответственность и подотчетность. Если ответственность — фетиш и в DataArt, и в профессиональном мире вообще, то с подотчетностью все далеко не так благополучно. Наоборот, я постоянно слышу или ощущаю: «Не лезь в мою зону ответственности!».

Почему мы не любим отчитываться? Во-первых, кое-кто любит, но не всегда и не обо всем. Вообще, для «политического животного» отчеты — важный инструмент укрепления собственного влияния. Но это уже ближе к самопрезентации и не считается. А на темной стороне реальности звучит: «Неважно, как сделал, важно, как отчитался!».

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

Не будем уже говорить о привычках не выносить мусор из избы, давать социально приемлемые ответы вместо искренних и просто врать по мелочам, чтобы выглядеть лучше. Это превращает подотчетность в творческий процесс. Да, творчество, чувство вины и раздражение от того, что лезут в твои дела... Страшная смесь!

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

Что значит «прокачать аккаунтабилити»

Итак, мы решили стать удобными для коллег, не теряя возможности вносить свои идеи и принимать свои решения. Для этого нужно думать, как быть для коллег доступным, предсказуемым и понятным. Стоит учитывать, что у всех разные контексты, которые искажают информацию. О нас говорят по-разному, и нас плохо понимают. Я попробую выделить несколько уровней ответственности в компании — годится для любого более-менее крупного бизнеса — на каждом из которых магия аккаунтабилити становится все заковыристей.

Мне видятся шесть уровней, каждый включает и никогда не исключает предыдущий:

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

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

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

Colleague Level (доступность и самостоятельность)

Активности

Приходя в новую компанию, стоит научиться играть по местным правилам, писанным и неписанным. Обычно, чтобы упростить этот процесс, в компаниях предусмотрены онбординг, Welcome Book, материалы на внутренних сайтах. Предполагается, что с их помощью коллега сам будет правильно сообщать о болезнях и отпусках, знакомиться с требованиями информационной безопасности и следовать им, и немногое другое. Это писаные правила.

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

Следование процедурам дается многим на удивление трудно, и мой совет — не додумывать, минимизировав момент творчества. Сомневаешься — спроси, прими совет буквально и следуй аккуратно, но не пускай в голову вредную мысль «как бы это сделать, чтобы было лучше». Она превращает дело на две минуты в мучение на полчаса и заставляет подсознание защищать нас, вытесняя процедуру из памяти и расписания.

Можно изобрести себе лайфхаки. Например, моя деятельность сильно фрагментирована. Потому я планирую свое расписание, важные дела и заполняю PM — программу учета рабочего времени — вперед недели на две-три. Если что-то идет не по плану, это исключение, и я правлю PM. Так я не убрал творческий элемент, а превратил его в созидательный.

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

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

• Если не понимаешь, почему или зачем и как что-то сделано, спроси у вовлеченных и аксакалов. Если объяснения убедительны, то все, а вот если «потому что так всегда было» или «потому что так говорит кто-то», вполне вероятно, что удалось найти «мертвый код» или неэффективность, исправление которой — большой вклад в общий успех.
• Просто говорить, что что-то плохо, — позиция не всегда бесполезная, но спорная. «Мы не врачи — мы боль», «мы протестуем, потому что надо же что-то делать» и все подобные заходы на работе выглядят не очень.
• Когда придумал решение и готов предложить изменения, найди группу коллег, которые смогут поддержать петицию. Поиск сторонников и обсуждение уберегают от глупых или слишком сложных и трудно объяснимых запросов. Коллективные петиции в DataArt всегда получают высокий приоритет, вероятно, это может сработать и в других компаниях.

Манифестация

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

Репутация

Помните: ваша репутация формируется не вообще, а в глазах конкретного человека. Вкладывайтесь в репутацию надежного и понятного партнера в глазах каждого, с кем имеете дело. «Я уже всем все сказал и доказал» не работает: всех много, а пижонство обычно доказывает нечто обратное тому, что мы сами о себе думаем. Не стесняйтесь просить у коллег обратную связь. Во-первых, все любят, когда интересуются их мнением, и очки репутации вы получаете автоматом. Во-вторых, если в ответах что-то удивляет, это повод задуматься. Способность рационально обсуждать себя и свои отношения с окружающими вместо рационализации и самоманипуляций уже стоит целого левел-апа.

Professional Level (Профессиональная ответственность)

Активности

Профессионал управляет собой и ожиданиями окружающих от себя.

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

Если профессионал не справляется с задачей или не успевает в срок, это уже проблема. Нормальная, регулярная, естественная, но проблема. Как говорят коллеги из «Стратоплана», чаще всего не умеешь или не можешь, а люди подумают, что не хочешь. Тут два принципа.

Проси помощи, как только можешь задать правильный вопрос, не в стиле «какого-такого тут все не работает?». Помогут — не помогут, но ты не упрекнешь себя, что не сделал все, что мог.

Второй принцип — recovery, восстановление репутации. Каждый косяк — лишний повод продемонстрировать лояльность. Извинись, исправь напоказ, проставься мороженкой или пивом, наговори комплиментов всем, кто помог или просто простил.

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

Манифестация

У всех нас есть профессиональные и личностные ограничения, о которых лучше коллег проинформировать. Например, я могу решать сложные задачи, используя воображение и образное мышление. Но это дорогой метод, получается долго и тяжеловесно. А решать проще я умею хуже других. Потому или долго что-то пережевываю с коллегами или сам с собой, или просто соглашаюсь и делаю. В режиме исполнителя я тоже работаю нормально, но нуждаюсь в указаниях. Потому учу коллег пользоваться собой. Например, если надо написать комментарии в прессу, мне нужны: тема, объем, описание аудитории, цель. Я выдаю результат по одной странице в час что на приличном русском, что на корявом английском. Задание написать «что-то хорошее для всех произвольного объема» я выполнить просто не способен.

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

Репутация

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

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

Leadership Level (Ответственность за профессиональную группу)

Активности

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

На этом уровне быть групповым, но добрым и желательно веселым протезом совести очень полезно. А следить надо, чтобы чувства вины не оставалось ни у вас, ни у коллег.

Манифестация

Если речь о сработавшейся команде, инструкция по ее использованию — вещь понятная. Группы, как ни парадоксально, попроще личностей, и внутренний коллективный договор, чаще неявный, легко превратить в основу для договора с окружающими. Лидер должен уметь говорить за группу вовне и правильно решать проблемы внутри группы, советуясь и обсуждая выгодный всем публичный имидж.

Репутация

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

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

Project/Program/Area Manager (Ответственность перед несколькими стейкхолдерами)

Активности

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

Суть внешнего планирования сводится к приданию области ответственности потребительских свойств и систематическому управлению ожиданиями. Внутреннее планирование — процесс координации усилий для оправдания ожиданий.

Важно различать внешнее и внутреннее планирование, чтобы не уподобляться карикатурному стартаперу, сообщающему команде: «Я пообещал инвестору порвать рынок! Всем бежать действовать по этому плану!».

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

Во внутреннем планировании жесткий план — чаще во вред. Допустим, у вас есть несколько задач. Если четко расписать время на каждую, какие-то получат избыток времени, какие-то — недостаток. Чем заполнить избыток времени, коллеги найдут, а вот с недостатком справляться уже тяжелее. Потому изобрели Agile и прочие мелкоитерационные методики, позволяющие эффективно делать дело. Высокому начальству они заходят не очень, и внутри мы можем быть сколь угодно Agile, но, если у клиента есть ограничения бюджета и демо на выставке в ноябре, помнить об этом — наша проблема, как и рапортовать об угрозе плану заранее, предлагая варианты решения проблемы.

Манифестация

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

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

Донести до клиента суть происходящего, формировать ожидание и работать над общением — во многом все еще искусство, которому учатся, наблюдая за работой мастеров. Хотя Agile и сделал многое для сближения формального и неформального уровня, проверить подготовку клиентов и способностьработать по согласованным и даже одобренным принципам — задача менеджера.

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

Репутация

Деловая репутация с этого уровня формируется в процессе отношений, и простых рецептов становится все меньше.

Но один совет я могу дать. Много саморекламы в начале, как и слишком уверенное поведение, завышают ожидания, которые потом трудно оправдать. С другой стороны, уверенность в себе — залог сильной репутации. Воспользуемся тем, что в памяти остается эмоциональное и отношения можно потренировать. Поднять проблему, изменить план или попробовать расширить бюджет на старте проекта относительно безопасно, поскольку на корректировку есть и время, и силы. Только язык надо использовать правильный: клиент должен понять, что мы хотим вместе с ним добиться успеха и разобраться со всем, что может помешать. Так сформируем понимание, что проблемы неизбежны, но мы уверенно с ними справляемся. На практике часто видим обратное — репортинг в стиле «все хорошо и нет проблем», пока можно скрывать трудности.

Account Unit Manager Level (Управление частью бизнеса)

Активности

Управление аккаунтом или подразделением означает, что вы работаете с портфелем проектов и задач, у стейкхолдеров которых почти наверняка разные интересы, и они необязательно готовы сотрудничать друг с другом. Расстановка приоритетов и разрешение конфликтов, принятие рисков и нахождение компромиссов с неизбежными потерями становятся повседневностью.

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

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

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

Манифестация

Редко получается быть идеальным на всех фронтах, но на бизнес-уровне надо понимать свои ограничения и искать в команде партнеров, способных компенсировать ваши недостатки. Нет ничего зазорного в том, чтобы признавать пробелы в собственном образовании или арсенале управленческих инструментов — так легче найти коллег, которые смогут помочь. Да, им придется платить, как минимум, благодарностью и ответной помощью, но так вы приобретаете собственную часть человеческого капитала. Беспокойство должна вызывать ситуация, когда вас окружают ваши же копии по стилю и профессиональному профилю. С ними легко и удобно, но они и от ошибок вас не уберегут, и в исправлении не помогут. Придется жить с убеждением, что «если хочешь сделать хорошо — делай сам».

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

Репутация

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

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

Business Administration Level (Управление бизнесом)

Активности

Описания деятельности топ-менеджера бывают очень разные. От визионера, мудреца и энергичного лидера до хитрого политика, умело лавирующего в потоке случайных событий и разговоров. Мой опыт с годами заставляет все больше ценить в руководителях уровня компании компетентность.

Компетентность приходит из образования и опыта. Образование помогает найти общий язык с коллегами и понять место твоей компании в общей экосистеме бизнеса. Опыт дает понимание, как вещи работают конкретно у нас. Разнообразный опыт помогает руководителям понимать, как вещи могут работать вообще.

Если организация большая, то быть 360-градусов-суперменеджером трудно. Потому любой топ-менеджер зависит от команды и полагается на нее. Понимание людей и понимание, кто что может и должен делать, — ключевое. Приходится брать на себя риски, просто доверяясь коллегам.

Потому аккаунтабилити для топа — политическая игра, способность не подставиться под формальные обвинения и максимально управлять ожиданиями стейкхолдеров и удовлетворять их. Чем больше в бизнесе материальных активов, тем важнее формальная сторона и тем секретнее и ожесточеннее борьба подковерная.

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

Манифестация

Для менеджера бизнес-уровня манифестация — рабочий инструмент и служит определенным целям. Каким бы ты ни был, коллегам придется к тебе приспособиться, а образ сложится из стереотипов и немного — из твоих реальных действий. Чем больше индивидуальности и меньше стереотипов, тем лучше, тем проще. Потому важно постоянно объяснять себя, писать статьи, проводить семинары, встречи, выступать публично, сотрудничать с масс-медиа. Тексты и записи продолжают работать, даже пока ты спишь. Конечно, one-to-one митинги — самый мощный инструмент, но нереально дорогой.

Репутация

Репутация топ-менеджера формируется через его способность действовать решительно в условиях стресса и неопределенности, снимая напряжение с владельцев компании и с коллектива. Очень мало коллег числят себя в одной референтной группе с высшим руководством, потому сотрудникам все равно, что происходит с начальством (оно типа богатое и обязано быть счастливым, ох). Владельцев компании чаще волнуют их активы, успех бизнеса, за который отвечает топ, но не сам руководитель-человек. Страшно ведь думать, что начальник пустит твою компанию по ветру просто от расстройства или усталости.

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

И большие неприятности, и неожиданный успех — возможности для усиления репутации. Только в случае успеха, если начальник тянет одеяло на себя, он «отбирает» успех у коллег, хотя куда разумнее стимулировать ощущение общей причастности. Потому проблемы лучше, как ни парадоксально: тут претендентов на таскание каштанов из огня немного и можно выступить — искусство в том, чтобы не сгореть.

Выводы

Аккаунтабилити, как и любая другая часть профессионального и личностного профиля, может быть и драйвером развития, и узким местом, ограничителем. Даже при отсутствии сродства достижение гигиенического уровня позволит раскрыть свои сильные стороны полнее. Высокая кооперативность, умение общаться, понимать и объяснять с легкостью компенсирует слабости с подотчетностью везде, кроме формальных аспектов.

[Олександр Краковецький — CEO компанії DevRain, співзасновник «ДонорUA», Microsoft Regional Director, Microsoft AI Most Valuable Professional, кандидат технічних наук]

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

Про розробку програмного забезпечення

Ілюстрації Аліни Самолюк

Припустімо, є завдання — посадити на городі картоплю. Звісно, у вас є багато опцій, як це зробити.

Ви можете знайти людину з трактором, яка приїде і посадить вам картоплю, а також людину, яка буде стежити, щоб людина з трактором правильно посадила картоплю. Вони приїжджають зі своєю картоплею. Це аутсорсинг (outsourcing).

Ви можете знайти людину, яка на вашому тракторі посадить вам вашу картоплю. Це аутстафінг (outstaffing).

Ви можете знайти людину, яка прийде і зробить заміри городу, запропонує декілька моделей тракторів і режиму роботи тракториста. У цьому випадку картопля посаджена не буде, але ви будете знати найкращий спосіб, як це зробити. Це R&D, або науково-дослідний інститут.

Ви можете покликати сусіда Колю, щоб він посадив вам картоплю за пляшку самогону і дві пачки цигарок. Це фриланс (freelance).

Ви можете покликати всіх своїх родичів, сусідів, друзів і разом посадити картоплю. Це краудсорсинг (crowdsourcing).

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

Ви можете взяти плуга, кілька відер, картоплю, книгу «Посадка картоплі за 21 день» і сам посадити картоплю. Правда, якщо вам потрібно буде посадити інший сорт картоплі, аніж той, про який йдеться в книзі, то доведеться перекопувати весь город ще раз. Ризик: може прийти сусід вночі й викопати вашу закопану картоплю. Це розробка на WordPress.

Ви можете взяти лопату і посадити картоплю на городі, де вже є добриво, накопані ямки й стоять стрілки, за якими зрозуміло, в якій послідовності потрібно садити картоплю. Це розробка на .NET/C#.

Ви можете спочатку зробити лопату, сконструювати відра, вивчити склад ґрунту, після чого порахувати кількість ямок і послідовно одну за одною заповнювати картоплею. Не пропускаючи жодної ямки. Це розробка на C++.

Ви можете прийти до голови радгоспу і сказати йому, що чудово знаєте, як садити картоплю, проте цього року ви її садити не будете, але 100% займетесь цим наступного року. І це буде реально круто, а врожай буде в 10 разів більший за урожай сусіда. Тому вам потрібні зараз гроші, лопати, трактор, тракторист (краще два), п’ять копачів і секретарка. Це стартап.

Ваш прадід садив картоплю, ваш дід садив картоплю, ваш батько садив картоплю. І ви теж продовжуєте садити картоплю. Це підтримка продукту (support).

Копаючи картоплю, ви час від часу викопуєте ту, яку садив ще ваш батько і дід. Це legacy-код.

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

Ви посадили картоплю. За деякий час вона стала проростати. І на вашій картоплі з’явилися колорадські жуки. Ви починаєте їх труїти, збирати вручну, давити і палити. Більшість з них вдається знищити, але скоро вони де-не-де з’являються знову. Це відладка (debugging) коду і виправлення помилок (bug fixing).

Ви посадили картоплю. На город прийшов ваш батько і сказав, що картопля посаджена неправильно, бо рядки криві і ви забули залишити місце для буряків. І тому вам треба пересадити частину картоплі. Через два дні, коли ви закінчуєте роботу, приходить ваш дід і каже, що глибина, на якій ви закопали картоплю, недостатня, тому вам потрібно перемістити всю картоплю в лунках на 5 см нижче. А сам йде пити пиво з сусідом Колею і вашим батьком. Це керівник команди (Team Lead), проджект-менеджер (Project Manager) і рефакторинг (refactoring).

Ви хочете трохи підзаробити. Йдете до сусіда Колі й кажете, що хочете допомогти йому садити картоплю. Сусід просить вас показати найбільшу картоплю, яку ви торік виростили, а також назвати імена інших сусідів, яким ви вже садили картоплю. Сусід також питає, чому ви прийшли саме до нього садити картоплю, на що маєте відповісти, що все життя мріяли садити картоплю лише на його городі. Потім вас попросять пояснити різницю між граблями і садовими ножицями, розповісти про найкращі граблі, з якими доводилось працювати, а також пояснити процес заготівлі сіна та чистки колодязя. І лише після того, як мати сусіда підтвердить, що «це ж Ольчин малий — тої, що хата на краю села», вам видадуть найгіршу лопату і ви почнете садити картоплю. Це інтерв’ю в аутсорсингову компанію.

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

Біля вашого села є велике поле, де люди з навколишніх сіл викидають свою картоплю, а іноді й інші овочі. Хтось викидає гнилу картоплю, а хтось — гарну. Тому ви ухвалюєте рішення не садити свою картоплю, а замість цього періодично навідуєтесь на поле, щоб назбирати картоплю там. Це Stack Overflow.

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

Ви друкуєте на принтері 1000 світлин з картоплею. Кожну продаєте своєму сусіду за гривню, розповідаючи, що садити реальну картоплю — то минуле століття і вже дуже скоро ця реальна картопля нікому не буде потрібна, а всі будуть їсти світлини картоплі. А оскільки надрукувати нові світлини в майбутньому буде неможливо, то ці світлини зростатимуть у ціні. Оскільки реальна картопля є у всіх, а світлин немає ні в кого, то сусіди з радістю купують світлини. Але на вечерю все ще варять реальну картоплю. В цей час у сусідньому селі інші люди продають інші світлини картоплі й розповідають, що лише ці фотки будуть відомими за 10 років. Це біткоїн (bitcoin).

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

Ви живете в селі, де вже 20 років ніхто не садив картоплі. Але ви впевнені, що десь вона є. Тому берете лопату і починаєте перекопувати все підряд — городи, стежки, поля, лісопосадки й навіть озера. Через деякий час наполегливої праці вам таки щастить і ви знаходите картоплину. Невдовзі вже все село починає шукати картоплю, перекопуючи все підряд. Це майнинг криптовалют (cryptocoin mining).

Картопля багато може розповісти про того, хто її виростив. Зокрема, чи хороший та сумлінний хазяїн її виростив, чим удобрював землю, якими інструментами користувався, чи виростив він її сам, чи, може, просто вкрав у сусіда, а ще чи гарна у нього ґаздиня (дружина).

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

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

З часом, щоб знайти картоплю конкретного селянина, потрібно перебрати гори сміття. Це відкриті дані (open data) і data.gov.ua.

Ви накопали багато картоплі. До вас приїхав голова колгоспу і видав документ, де написано, скільки картоплі ви накопали. Але щоб прочитати цей документ, вам потрібно їхати до голови колгоспу, бо тільки він єдиний в селі вміє читати. Інші сусіди можуть бачити документ, але ніхто не розуміє, що там написано. Це хешування (hashing, hash function).

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

Ви купили ділянку, виорали та удобрили город, купили лопати, відра, картоплю і протягом тижня її посадили. Дід з бабою доглядають город, борються з колорадськими жуками, знищують бур’яни. А в кінці літа самостійно викопують картоплю і несуть до погреба. Це on-prem, або наземна інфраструктура. А дід з бабою — системні адміністратори.

Якось до баби з дідом приїхав внучок з міста і запропонував частину городу засадити картоплею, а якщо не вистачить, то купити й привезти з магазину. Це гібридна інфраструктура (hybryd).

Через кілька років, коли вартість палива збільшилась, у діда знайшли грижу, а колорадські жуки з’їли третину врожаю, внучок переконав бабу з дідом відмовитись від свого городу, і всю картоплю почати купувати в магазині. Це хмарна інфраструктура (cloud). А внучок — DevOps.

Якось сусід, що жив через дорогу, запропонував бабі з дідом, що буде сам купувати картоплю в магазині й приносити їм за пляшку самогону. Баба і дід погодились. Це модель підписки (subscription model).

Ідея сподобалась й іншим жителям, і сусід почав возити картоплю всім охочим. Це системи доставки типу Zakaz.ua.

Приїхав якось до баби з дідом їхній наймолодший внучок, який тільки школу закінчив і хотів навчитись садити картоплю. Про те, як росте картопля, внучок знав лише з уроків біології в 6 класі, чим дуже пишався. Це вайтішнік, а уроки біології — онлайн-курси типу Coursera чи Prometeus.

Внучок взяв лопату і почав копати ямки на городі, не порадившись з дідом і бабою. Йшов грудень. Це Junior Developer.

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

Намалювавши схему городу, дід сказав, що садити будуть не раніше як першого травня, а закінчити треба до п’ятого. І обвів цю дату в настінному календарі. Це планування задач і створення діаграми Ґанта. 5 травня — це дедлайн.

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

— Ні, внучку. Треба все садити за планом. Ніякої самодіяльності! — прокричав дід. Це модель розробки «водоспад», або «каскадна модель» (waterwall).

4 травня пів городу ще не було засаджено. Тому дід покликав бабу, сусіда, іншого внучка, і всі разом активно почали садити картоплю. Це Kanban.

Про штучний інтелект і машинне навчання

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

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

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

Ви приходите на город, а там роботи саджають картоплю. Оптимальний розмір картопин, глибина лунок і швидкість посадки розраховується в реальному часі на базі таких показників, як швидкість вітру, вологість, температура, вартість картоплі на світовому ринку і акцій Kartoplya Inc. на Нью-Йоркській біржі. Це штучний інтелект (Artificial Intelligence).

Вам потрібно посадити картоплю, але ніхто у вашій сім’ї не вміє це робити. Тому ви йдете до сусіда і дивитесь, як він садить картоплю. Через деякий час всі садять картоплю як ваш сусід. Це машинне навчання (Machine Learning).

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

У процесі сортування виявилось, що маленьку картоплю потрібно додатково ділити на маленьку і дуже маленьку, а також окремо розкладати за сортами.Це кластеризація з невідомою кількістю кластерів.

Ви берете картоплю і не знаєте, вона велика чи середня. Це нечітка класифікація (fuzzy classification).

Ви берете картоплю і розумієте, що це картопля. Ви берете іншу картоплю і розумієте, що це картопля. Ви берете огірок і розумієте, що це огірок. Ви берете буряк і розумієте, що це буряк. Це розпізнавання образів (image recognition).

Ви берете картоплю і розумієте, що це картопля. Ви берете іншу картоплю і розумієте, що це картопля. Ви берете огірок і розумієте, що це не картопля. Ви берете буряк і розумієте, що це не картопля. Це бінарна класифікація.

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

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

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

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

Ви садите картоплю. Ваша бабця каже садити рідше. Ваш дід рекомендує робити навпаки. А мама взагалі каже, що треба посадити помідори. Крім того, мама каже, що лунки варто робити глибшими. Ви повинні правильно виконати всі настанови. Це розпізнавання та обробка природної мови (natural language processing).

У вас є цілий погріб з картоплею різних сортів. Вам потрібно вибрати сорт, який дасть найкращий врожай. Сусід, що проходив мимо, каже, що найкращий врожай дасть сорт А. Це просунена аналітика (advanced analytics).

— Наступного разу ми засадимо город на два дні раніше! — сказав дід після того, як город був засаджений. Це модель прогнозування (prediction model), що була побудована на історичних даних (historical data).

Щоб швидше посадити та викопати картоплю, замість лівої руки ви прироблюєте металеву руку з моторчиком. Продуктивність ваша значно зростає. Це трансгуманізм (H+).

Ви постійно садили картоплю під лопату. І всі ваші сусіди постійно садили картоплю під лопату. А потім ви почали садити картоплю за допомогою плуга. І всі ваші сусіди почали садити картоплю за допомогою плуга. А потім ви почали садити картоплю за допомогою трактора. І всі ваші сусіди почали садити картоплю за допомогою трактора. Це машинне навчання.

А потім приїхав Ілон Маск на гіперлупі й сказав, що більше садити картоплю не треба, бо він її буде садити на Марсі. Це сингулярність.

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

Про діджиталізацію та «державу в смартфоні»

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

Щоб був хороший врожай картоплі, потрібно удобрити землю. Але добрива купити забули, а город віддали в оренду, де на ньому грають футбол.

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

Вчора їздили в сусіднє село і підписали меморандум про обмін досвідом про садіння картоплі. Правда, останні 10 років ми картоплю не садили і не сильно розуміємо, як це робити. Але вечорниці були класні. А, ще лісапед подарували!

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

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

Вирішили, що будемо вирощувати е-картоплю. Не ясно, як її їсти, але звучить круто!

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

Будемо запрошувати молдован, щоб у нас в селі садили картоплю. Чекаємо зі своєю картоплею і тракторами. Ми можемо показати дорогу, як доїхати. Ну... як дорогу.

Поставив своїй бабці вайбер. А вона мені зробила смузі із самогону. Ще б газ провели — взагалі було б добре.

Тут у вайбері сказали, що зроблять електронні права. Що таке права?

Потрібно посадити картоплю. Покликав кума, який ніколи не садив картоплю. Але ж то кум, швидко навчиться!

Коли кум почав запрягати корову в плуг, я почав здогадуватись, що щось тут не так. Але кум сказав, що багато разів так робив. Ну кум знає, як робити. Хай робить!

Через тиждень перевірив роботу. Картопля не посаджена, а кум з дідом Юхимом п’ють самогон. Корова стоїть прив’язаною на городі до лісапеда.

За місяць спитав кума, як там картопля. Кум сказав, що все зроблено, а сам звалив на ПМЖ в сусіднє село. Корову забрав сусід. Виявилось, що це його корова.

Картоплі немає. Комора порожня. Кум змінив прізвище і не відповідає на вайбер.

Терміново взяв двох хлопчиків, що живуть через дорогу. Сказав посадити картоплю за 2 дні. Хлопчики погодились, попросили 2 яблука та покататись на лісапеді. Я погодився.

До вечора посадили картоплю. Задоволений.

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

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

Про лідерство, бізнес і стартапи

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

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

3. Щоб стати мільярдером, спочатку потрібно посадити кілька гектарів картоплі або мати друга-фермера, який допоможе посадити картоплю швидше.

4. У кожного Джобса завжди був свій Возняк, який активно садив картоплю, поки умовний Джобс займався всякою хернею.

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

6. Усі найкращі копачі картоплі були скромними, педантичними людьми із 30+ річним стажем, які майже ніколи не йшли на ризик.

7. Більшість історій успіху, коли картопля була висаджена до 1 травня — це помилка тих, хто вижив.

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

9. Вся стартап-культура («посадімо менше картоплі цього року» або «посадімо під плужок», або «купімо картоплю в магазині») працює лише в теорії. А по факту повна маячня.

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

11. Немає жодної кореляції між «корпоративною культурою» садіння картоплі, бажанням садити картоплю і майбутнім урожаєм.

12. Жодне поле з картоплею не було посаджене без навозу, криків, родичів і кумовства, а також феноменального збігу вихідних днів.

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

14. Підприємництво неможливо в країні без культури, де люди охоче продають і купують картоплю.

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

16. Всі брешуть і обманюють, що саме їхня картопля не кропилась хімікатами.

17. Вся економіка посадки картоплі зводиться до єдиної формули: кількість викопаної картоплі > кількості посадженої картоплі.

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

Про ролі на проєкті та HR-процеси

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

На городі ж завжди є чітка ієрархія. Є бабуся, яка без калькулятора знає, скільки городу треба висадити, в які терміни й що має в результаті вирости. Це Product Owner, який формує технічні вимоги до проєкту (technical requirements) та визначає критерії успішності (definition of done).

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

Толік і бабка також обговорили, що буде посаджено на якому городі й де буде проходити стежка між їхніми городами. Це інтеграційні тести (integration tests).

Дід заводить трактор, починає нарізати рядки, в які буде висаджена картопля. Це архітектор програмного забезпечення (Software Architect).

До речі, деякі рядки — рівні, а деякі — криві. Це все тому, що архітектор має бути хороший, але використовуємо те, що є.

Далі виходить мама, яка керує загальним процесом садіння картоплі. Вона кричить на тата, щоб той швидше підносив картоплю, підганяє внучків і шипить на курей і гусей, що бігають городом. А ще викидає погану картоплю та постійно свариться з бабкою, якій постійно здається, що все йде не за планом і якщо так всі будуть працювати, то картопля в цьому році не виросте. Мама — це керівник команди (Team Lead), а тато — технічний лід (Technical Lead).

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

Середній внучок найбільш засмучений. Він вже достатньо дорослий, щоб виконувати всі типи робіт — і копати, і садити, і колоти дрова, і годувати корову, але в сільський клуб його ще не відпускають по вечорах, а Оленка тусить з його старшим братом. Це Middle Developer.

Молодші внучки бігають по городу, кидаються грудками один в одного і при першій же нагоді тікають у тіньок або пограти у футбол. На них кричить мама, сердиться старший брат, але ніхто сильно не гримає, бо розуміє, що вони ще діти. Це Junior Developers.

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

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

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

Наступного року внучок поїхав в інше село садити картоплю. Це прийняття пропозиції (offer) і перехід в іншу компанію.

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

Якщо вам сподобалась стаття, підтримайте волонтерський проєкт DonorUA — автоматизовану систему рекрутингу та управління донорами крові в Україні.

Недавно я уже рассказывал о себе в статье об универсальных и узкопрофильных программистах. Напомню только, что в IT я 35 лет, занимался разработкой, формировал и управлял командами, преподавал компьютерные науки и информационную безопасность. Теперь в DataArt помогаю коллегам профессионально развиваться — отлаживаю процессы, с помощью которых можно построить карьерный план, повысить квалификацию или сменить технологию на более перспективную.

В этой статье хочу поделиться рекомендациями с теми, кто собирается стать программистом и пока думает, каким именно. На что обращать внимание при выборе самой первой специализации, стоит ли идти на поводу у собственных чувств, можно ли угадать перспективную технологию и зачем все-таки учить английский? Надеюсь, эти советы пригодятся студентам и школьникам, а также всем, кто решил сменить свою сегодняшнюю работу на IT.

Иллюстрация Ульяны Патоки

Совет первый: подумать о теоретической науке и пробовать знания на практике

Если вы решили идти по классическому пути, то есть начали с обучения в вузе, обратите внимание на Computer Science как на академическую дисциплину. Не уверен, что достаточный процент студентов, кто мог бы развивать это направление именно в университетах, задумывается о такой возможности. Между тем некоторые мои однокурсники и однокурсницы делают в науке по-настоящему интересные вещи. Правда, в основном за пределами Украины. Впрочем, карьера ученого подойдет не всем: например, мне всегда было трудно понять, какое практическое применение мы сможем найти чисто теоретической информации, только что полученной на лекции. Но если для вас такая связь между вполне абстрактными выкладками и реальной разработкой чаще всего очевидна — возможно, склад вашего ума позволяет рассчитывать на серьезные успехи в теоретической кибернетике.

Тем же, кому (как и мне) неинтересно долго разбираться, каким образом построения теоретиков кибернетики воплощаются на практике, стоит поскорее включаться в реальные проекты. Например, я на первом курсе все еще не очень хорошо понимал, чему учусь и кем стану в будущем. Но поскольку мы с однокурсниками в основном были ребятами взрослыми, к тому же после армии вернулись в совершенно другую страну, то нам была необходима работа. Параллельно учебе кто-то умудрялся устроиться проводником, вагоновожатым, шофером. Мне же повезло попасть в вычислительный центр Академии ПВО: военные разработки тогда были нереально крутыми, и я быстро разобрался, что делают программисты на практике. Коллеги занимались виртуализацией, моделировали налеты авиации и проектировали радиолокационные станции. Все это было невероятно интересно, поэтому я практически жил на работе.

Наверное, самый правильный способ понять, насколько нравится то или иное дело, потрогать его руками. Вне зависимости от того, какой из двух сценариев вы выбрали: курсы/самообразование или классику с пятью годами университета, окончания учебы дожидаться не нужно. Сейчас есть возможность попасть в продуктивную среду раньше, искать практикантские вакансии или пробовать писать что-то свое с друзьями. Главное — убедиться, что такая работа приносит удовольствие.

Совет второй: доверять себе и анализировать эмоции

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

Язык программирования — прежде всего язык общения, причем не только с машиной, но и друг с другом. С одной стороны, это первый повод задуматься, близка ли вам выбранная профессия. С другой (и это очень хорошая новость) — если с удовольствием принимаете эти принципы мышления, вы на правильном пути. Прочувствовав основы разработки, гораздо легче овладеть любой из используемых технологий. Это значит, что входом в профессию может стать любой язык. Если сейчас таким часто оказывается, например, Python, почему бы и нет?

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

Вот как описывает процесс своей работы одна моя знакомая, начинающая программистка: «Сначала приходит идея — ты в восторге — пишешь код — оно не работает — ты проверяешь — перепроверяешь — вот оно, нашлось! — ан нет, показалось... — тебе хочется сдохнуть — и тут — бац! прозрение! — кайф». По-моему, идеально!

Кстати, я слышал, что многие из тех, у кого пока немного опыта в реальных проектах, думают, будто в QA попадают люди, неспособные писать программы. Мол, если хочешь в IT, но вовремя не выучился на разработчика — иди в тестировщики. На самом деле, классными специалистами в тестировании становятся те, кому по-настоящему нравится доводить приложения до идеала.

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

Совет третий: не бояться ошибок и перемен

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

Но, если вам доставляет удовольствие сам процесс создания программы, ее тестирования или, скажем, организации разработки — весь прочий антураж поменять относительно несложно. Рынок IT динамичен, быстро оправляется после кризисов, компании на нем всегда конкурируют за специалистов, особенно увлеченных своим делом. Если вы открыты новому, подходящее предложение вас наверняка найдет.

В мире технологий при нынешнем доступе к информации и образованию главное — не лениться и не бояться нового. Сейчас достаточно списков популярных, высокооплачиваемых или любимых программистами технологий. Думаю, заглядывать в них стоит — любая информация может оказаться полезной. Но рассчитывать раз и навсегда угадать с платформой не приходится. Недавно многие говорили, что через год все будут программировать на Golang, но пока программируют на нем почему-то не все.

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

Совет четвертый: смотреть по сторонам и учить английский

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

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

Пожалуй, тем, кто начинал обучение с двумя экземплярами книги на всю команду из 120 человек, которые две недели распечатывали с дискеты в два прохода на матричном принтере, а затем их выдавали на руки под честное слово и запись в журнале, остается только завидовать сегодняшним студентам. Необходимости самостоятельно дрессировать компьютер, действуя по наитию, теперь нет. Для поиска информации есть множество ІТ-сообществ и Google, жизнь без которого вообще сложно представить.

Однако нам необходимо быть готовыми к восприятию новых знаний, вплоть до терминологии. Я, например, совсем недавно на брейнсторме по искусственному интеллекту познакомился с двумя совершенно новыми для меня темами, о которых никогда раньше не слышал. За три с лишним десятка лет в IT. Не скажу, что я теперь в них прямо уж эксперт, но поддержать разговор с заказчиком в будущем смогу. Хотя мне пришлось немного разобраться в матчасти и опять-таки погуглить.

Это подводит нас еще к одному очень важному вопросу — английскому языку. Думаю, для программиста сейчас его знание оказалось даже важнее математики. И не только потому, что знание языка позволяет общаться с иностранными заказчиками, упрощает поиск работы и построение карьеры. Способность понимать английский на порядок расширяет возможности дообучения в любой области, ведь многие публикации (думаю, едва ли не 80%) никто не собирается переводить на национальные языки.

Совет пятый: пробовать силы и быть азартным

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

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

В свое время я писал (или хотя бы пытался писать) на всем, на чем писалось и что воспринимал компьютер. Assembler, PL, FORTRAN, REXX, LISP, FoxBase, FoxPro, C, C++, .NET. Все было интересно и при этом расширяло кругозор, позволяло понять, что вот это — моё, а это как-то не очень. Например, попробовав силы в программировании на языке LISP, я быстро понял, что этот уровень мне сходу недоступен и требует длительного и глубокого погружения. Круто, конечно, написать программу, которая умеет, к примеру, модифицировать саму себя во время выполнения в зависимости от внешних условий, однако здесь я решил остановиться на уровне знакомства с теорией и глубокого восхищения.

Но, может быть, как раз вам это не покажется таким уж сложным? В любом случае не узнаете, пока не попробуете.

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

При этом, чтобы стать хорошим менеджером вовсе не обязательно быть лучшим программистом в мире. С другой стороны, если вы уже стали профессионалом в разработке программного обеспечения, вас намного легче примут коллеги, которыми вы пришли руководить (по крайней мере поначалу). В любом случае умение говорить с командой на одном языке очень важно.

В заключение скажу, что с выбором специализации тянуть не стоит. Пробуйте интересное направление на практике, наслаждайтесь профессией и меняйте сферу, если она показалась вам скучной. В случае если статья была вам интересной, посмотрите мой вебинар, посвященный этой же теме. Но я уверен, что вы определите собственный путь: прислушайтесь к себе и всё получится!

[Кирилл Захаренков до 2010 года работал как Embedded Software/Hardware Developer. Соавтор двух американских патентов. Последние 10 лет занимается управлением людьми. Иногда кодит в интересных проектах. В данный момент работает СТО в компании Dynamo Development,Іnc.Один из создателей украинского стартапа «Мій Дім Онлайн».]

В январе 2019 года вместе с DOU мы опубликовали статью «Crew resource management в IT-команде, или Чему нам поучиться у пилотов». Тема показалась мне очень интересной. Я решил подготовить больше материалов и поделиться с сообществом. Эта статья про важные принципы командной работы, коммуникации, межличностные отношения, про отношение к работе и многое другое.

Меня трудно назвать писателем. Я всегда восторгался людьми, которые при своей очевидной занятости находили время, чтобы подарить другим свои идеи и приобретенный опыт, будь то статья в интернете или ролик в YouTube. Я же считал себя закоренелым читателем. Неожиданно для меня материал получился объемный, и было решено разделить его на несколько статей. Большинство заметок я сделал, когда решил променять автомобиль на метро, чтобы не тратить уйму времени на мучительное пробкостояние. Так родилось название «Практики командной работы в записках из киевского метро». Этот материал может заинтересовать не только руководителей, но и рядовых членов команд. Надеюсь, это принесет вам пользу.

Для тех, кто не читал первую статью: «Методология Crew resource management (сокращенно CRM*) впервые была представлена NASA (National Aeronautics and Space Administration) на семинаре по авиационной безопасности в 1979 году. С 1981-гоона активно применяется в гражданской авиации, медицине и других отраслях, где человеческие ошибки могут привести к катастрофическим последствиям. CRM фокусируется не на технических аспектах работы, а на коммуникациях и межличностных отношениях членов команды. Именно поэтому она применима как для команд профессионалов, так и в повседневной жизни.

Сегодня о Crew resource management говорят, в основном, в среде пилотов гражданской авиации. Большинство материалов в сети существует на английском языке. Денис Окань — один из немногих, кто прикладывает множество усилий для того, чтобы познакомить с CRM русскоязычную аудиторию. В интернете вы можете найти много его статей и блогов, посвящённых этой теме. На мой взгляд, похожие принципы командной работы сегодня необходимы во многих сферах, где результат сильно зависит от взаимодействия между людьми.

Моя работа не является интерпретацией или переводом материалов и документов Crew resource management. Это скорее попытка предложить похожие принципы для применения в IT. Писатель и философ Ральф Уолдо Эмерсон писал: «Что касается методов, их может быть миллион, а вот принципов всегда лишь несколько. Человек, который освоил принципы, легко может выбрать собственные методы. У человека, который пробует методы, игнорируя принципы, непременно возникнут проблемы».

Аббревиатуру CRM часто применяют для обозначения Customer relation management. Не следует путать эти два разных понятия.

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

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

О правилах и ролях в команде

Все члены команды должны понимать суть и назначение установленных предписаний, а не бездумно следовать им.

Одна из моих знакомых скрам-мастеров начинала проводить стендап-митинг ровно в 11:00 и ни минутой позже, невзирая на отсутствие других участников Skype-чата. Конечно же, Scrum guide предполагает, что стендапы должны проходить регулярно и в одно и то же время, но отсутствие ведущих специалистов убивает весь смысл проведения такого мероприятия. Без сомнения, следовало повысить дисциплину команды в этом случае, но способ, который избрала моя коллега, был далек от достижения цели.

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

Команда должна пользоваться стандартными операционными процедурами для формализации простых процессов там, где это возможно.

Весь мир — театр.
В нём женщины, мужчины — все актёры.
У них свои есть выходы, уходы,
И каждый не одну играет роль.
Вильям Шекспир, монолог Жака из комедии «Как вам это понравится»

В сложившемся коллективе основные роли, конечно, распределены. На первый взгляд больше и нечего добавить. Все очевидно. Программисты программируют, тестировщики тестируют, менеджеры управляют.

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

Так происходит изо дня в день до тех пор, пока не случается что-то, что выходит за рамки привычного процесса. Как правило, команда оказывается к этому не готова. Заболел скрам-мастер, и вдруг не состоялся стендап.

Если не существует договорённости по поводу того, как коллектив реагирует на подобные обстоятельства, есть высокая вероятность, что команда проигнорирует их. Задача, не закрепленная за определенным человеком, зачастую остается незавершенной потому, что никто не взял на себя ответственность за ее выполнение.

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

Несомненно, в команде должен быть человек, призванный следить за тем, чтобы неожиданно возникающие задачи не потерялись в общем потоке. Это может быть руководитель группы или скрам-мастер, обеспечивающий исполнение командой принятых процессов. Если же такой человек временно не может исполнять свои обязанности, кто-то должен заменить его.

Каждый член команды должен быть готов выступить в другой роли по необходимости.

Одна из моих сотрудниц в ходе собеседования сказала кандидату, что мы нанимаем на работу не просто разработчика, а ищем члена команды. Готовность прийти на помощь коллеге, взять на себя участок работы ради того, чтобы вся группа достигла поставленной цели. Эти качества должны поощряться и культивироваться внутри коллектива. Сферы ответственности должны быть четко распределены и по возможности задокументированы, также должно быть понимание, кто кого «страхует» в том или ином случае.

В начале инженерной карьеры я часто задавал себе такие вопросы: что себе думают эти менеджеры? Почему такие красивые технические решения остаются без внимания? Когда стал начинающим менеджером, я узнал больше о том, что порой синица в руке покрывает 90 процентов потребностей, а погоня за журавлем в небе может завести проект в тупик.

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

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

Мне кажется, это поможет лучше находить общий язык с коллегами, а это важно в командной работе.

Нельзя не сказать о роли руководителя, который всегда присутствует в любом коллективе. Несмотря на современные принципы самоорганизующихся команд и демократичные подходы к управлению, за успех проектов и процессы в компании отвечают конкретные люди. Ответственность может быть только индивидуальной, а безответственность может быть коллективной.

Об этом хорошо говорит Радислав Гандапас в своих выступлениях. Не вдаваясь в точность формулировок, попробую передать суть сказанного: «В случае победы хороший военачальник скажет, что эту победу одержали его солдаты, сражаясь на поле боя. В случае поражения признает, что является главным его виновником. Готовность подписаться под результатом и есть основное определение ответственности».

Для руководителя эта ответственность может быть не только моральной и финансовой, но и нести за собой административное, а порой и уголовное наказание. Именно поэтому, на мой взгляд, последнее слово в принятии решения всегда должно быть за руководителем. Все члены команды должны это понимать и признавать его право на принятие окончательного решения.

Решение принимается ответственным за выполнение задачи/проекта лицом (зачастую руководителем) на основании информации и мнений, собранных у членов команды.

Позиция каждого члена команды должна быть принята во внимание, даже если она противоречит позиции руководителя. Руководитель должен поощрять сотрудников предлагать альтернативные способы решения задачи. Каждый член команды обязан принимать участие в обсуждении поставленных задач.

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

Границы команд по версии Радислава Гандапаса

Другой крайностью является ситуация, когда начальник, как кукловод, дёргает за ниточки своих сотрудников, лишая их самостоятельности в принятии экспертных решений. Мне нравится пример, который приводит Радислав касательно роли руководителя. Он рассказывает историю о двух племенах с различным подходом к выпасу овец. В одном из племён пастух идет впереди, проводя отару по пути, который он считает наиболее оптимальным для животных. Во втором племени пастух идёт сзади. Он следит за направлением движения стада, а овцы сами выбирают наиболее лакомые места на пастбище. Как результат второе племя превосходит первое по количеству и качеству собранной шерсти.

Про роль руководителя мы будем упоминать в каждом из последующих разделов.

Говоря о команде, мы предполагаем, что коллектив, который мы подобрали, хорошо мотивирован для достижения поставленной цели, ему интересно работать вместе и личные цели каждого сотрудника могут быть достигнуты в ходе проекта. В своей книге «Поток» Михай Чиксентмихайи описывает состояние, которое делает человека счастливым. Чтобы достичь его, должны соблюдаться следующие условия:

• деятельность человека осуществляется в рамках определенных правил;
• человек обладает знаниями и навыками, необходимыми для решения задачи, но проблема немного сложнее, чем предполагает его экспертиза. В результате этого совершенствуются его умения и навыки;
• поставлены ясные цели и существует обратная связь. Найден способ измерения прогресса в рамках выбранной системы целей;
• ощущается контроль над ситуацией. Сохраняется предельная концентрация над задачей, нет времени на анализ факторов, не относящихся к задаче. Концентрация настолько сильна, что изменяется чувство времени.

Если работа построена таким образом, чтобы каждый член команды ощущал состояние потока, группа будет максимально эффективной.

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

Чиксентмихайи описывает случай с рабочим Рико Меделлином, который работает на конвейере. Нельзя себе представить более монотонную и скучную работу. Он выполняет одну и ту же операцию около 600 раз за смену. Тем не менее Рико относится к работе так, как спортсмен к соревнованию. В ходе длительных тренировок он находит способ выполнять свою операцию за 28 секунд вместо 43, с которых он начал совершенствовать навыки. Рабочий доволен собой, но он не распространяется о своих успехах. Вскоре он поймет, что достиг максимума эффективности, и будет претендовать на более сложную работу. В книге «Поток» автор отмечает, что состязание приносит пользу до тех пор, пока служит для совершенствования навыков. Став самоцелью, оно перестает доставлять радость. Если целью становиться одержать победу над противником, а не выложиться по полной, радость в конце концов исчезает.

Каждый сотрудник, независимо от занимаемой позиции, роли и специализации, должен работать на результат команды, а не соревноваться с коллегами.

В среднем два из пяти проектов не достигают целей и ожиданий бизнеса, половина из них неуспешные из-за неэффективной коммуникации.
Статистика Института управления проектами (PMI)

Если вы думаете, что можете общаться в команде, как главный герой сериала «Доктор Хаус», то даже будучи гением, вам вряд ли удастся добиться расположения коллег и эффективно коммуницировать с ними.

Расскажу об одном случае из моей практики. Молодой сотрудник обратился с техническим вопросом к авторитетному коллеге. Суть вопроса была простой, и опытному инженеру хватило бы несколько минут, чтобы подтолкнуть товарища по команде к самостоятельному решению проблемы. Вместо этого он разразился тирадой на тему: чему вас учили на первом курсе института? Конечно же, после такой лекции молодой специалист уже не станет в будущем задавать «глупые» вопросы. Проблема, которая может быть решена за минуты, будет стоить бизнесу длительных часов поисков, проб и ошибок, которые необязательно заканчиваются успехом.

О коммуникации и критике внутри команды

Каждый член команды (независимо от роли или опыта), требующий разъяснений, должен получить необходимую для выполнения задач информацию в полном объёме без упреков и нареканий.

Чего греха таить, многие из наших коллег любят блеснуть своей экспертизой, начиная повествование с азов, а когда приближаются вплотную к тематике вопроса, предлагают почитать литературу.

Предоставляемая по запросу информация должна содержать прямые ответы на поставленные вопросы и быть доступной для понимания теми, кто их задал.

История знает много случаев, когда нарушение коммуникации между мастерами своего дела и новичками стоили людям жизни. З3-летний второй пилот Boeing 747 так и не отважился исправить очевидную ошибку своего опытного командира, и рейс KE8509 разбился через несколько минут после взлета недалеко от лондонского аэропорта «Станстед». 57-летнийкапитан воздушного судна до последней секунды пилотировал самолет по показаниям неисправного прибора, не обращая внимание на доклады бортинженера и показания других исправных приборов.

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

В команде следует создавать атмосферу, позволяющую людям открыто говорить о своих ошибках и регулярно разбирать причины их возникновения.

Каждому из нас необходима обратная связь от коллег. Конструктивная критика — один из наиболее быстрых способов получения нужной информации для совершенствования. Тем не менее важно то, каким образом человеку указывают на ошибки. Швейцарский писатель Макс Фриш сказал однажды: «Если ты думаешь, что узнал истину, подай ее другому, как подают пальто, чтобы удобней было надеть, а не тычь ей в нос, как мокрым носовым платком».

Занятный случай произошёл в одной из компаний, где мне довелось работать. На производственной линии в Китае перестал работать стенд для тестирования готовой продукции. Наш заокеанский менеджер поручил инженерам в Киеве незамедлительно разобраться с проблемой, чтобы избежать длительного простоя. Учитывая разницу во времени, задачу пришлось решать ночью в «пожарном» порядке.

Причину нашли быстро, поскольку отказа фактически не было, а персонал неверно использовал оборудование. Инженер, ответственный за решение проблемы, написал менеджеру письмо, в котором указал, что причина найдена. Далее следовало детальное техническое описание проблемы и обоснованные сомнения в умственных способностях работников производства.

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

Предметом критики должны быть результаты деятельности, а не личность коллеги.

Надо обладать определенным мужеством, чтобы заявить коллеге об его ошибке или признать свою неправоту. Наше подсознание строит множество барьеров, которые мешают открыто выражать свою точку зрения.

Опытные сотрудники и руководители должны явным образом заявлять о готовности выслушать критику в свой адрес.

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

Я попросил привести примеры и объяснить, почему возникло такое ощущение. В ответ не было предоставлено никаких фактов. Я пообещал, что сделаю все необходимое для обеспечения дружественной рабочей атмосферы в команде, а именно:

• перестану бить людей и кричать на них матом;
• не буду отбирать у сотрудников деньги;
• перестану подавать женщинам пальто, чтобы не выглядеть сексистом;
• буду разрешать сотрудникам ходить в туалет до завершения совещания;
• отстегну наручники ведущего разработчика от батареи, чтобы он мог время от времени ходить домой.

Другие способы решения проблем мне не пришли в голову, так как я не знал, на чем основывается шестое чувство коллеги.

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

Критика должна основываться на фактах, иначе не стоит ожидать исправления ситуации. Критика, не подкрепленная примерами, может вызвать обиду и поставить в тупик человека, на которого она направлена.

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

Процедура аттестации сотрудников, или, как принято говорить, плановое review — довольно тонкий инструмент, который требует осторожного обращения. Многие компании используют сложные методики, например, «ревью 360°». Такие инструменты позволяют собрать всесторонние отзывы о сотруднике от подчиненных, равных по рангу коллег, начальников и заказчиков. На мой взгляд, несмотря на то, что будет написано в отзывах и формах, основным критерием оценки сотрудника должны быть ответы на вопросы: может ли компания эффективно работать без такого специалиста и каковы последствия его ухода. Не отвергая других способов оценки коллег, я предлагаю использовать «квадрат Декарта».

Отдельного внимания заслуживают командные дискуссии. В них наиболее полно проявляются все качества членов команды. Тут вам и критика, и толерантность, и умение сфокусироваться на важном. Профессор Сирил Паркинсон в своей книге «Законы Паркинсона» сформулировал закон привычных сумм: время, потраченное на обсуждение пункта, обратно пропорционально рассматриваемой сумме. Другими словами, объем обсуждения обратно пропорционален сложности обсуждаемой проблемы. Это утверждение еще называют законом тривиальности.

Паркинсон демонстрирует действия закона на примере заседания менеджеров, на котором важным вопросам, таким как постройка реактора на 10 миллионов фунтов, уделяется минимум времени. Основные дискуссии возникают вокруг постройки хранилища для велосипедов сотрудников стоимостью в 350 фунтов. Этот эффект еще называют эффектом велосипедного сарая.

Любое совещание должен модерировать человек, способный направлять обсуждение в конструктивное русло.

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

Отвергая наши предложения по реализации функционала, моя сотрудница не могла толком объяснить причины, почему то или иное решение ее не устраивало. В конце концов мы решили прервать затянувшиеся дебаты и предложили коллеге проработать вопрос и предложить собственный вариант в течение нескольких дней. Девушка восприняла поручение с обидой. На следующем совещании она презентовала инновационный подход, который был единогласно принят командой. Мы по-прежнему используем ее идею в продукте. Моя коллега гордится своим вкладом, а обида, надеюсь, рассеялась.

Критикуя проекты решений в ходе обсуждений, каждый член команды должен объяснить причину критики, сообщить о рисках и предложить свой вариант решения. Критика без объяснений неприемлема.

Далее следует обещанная в начале таблица с перечнем хороших и плохих практик к описанным выше принципам.

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

Здравствуйте. Меня зовут Владимир Кожаев. Программирую я профессионально (то есть получаю за эту работу деньги) с 2004 года — больше шестнадцати лет. Перед моими глазами прошло много всякого, поэтому с возрастом стал циничен как хирург. В этой статье хочу рассказать о разных программистских работах честно, без приукрашивания действительности — перед чтением налейте себе коньячку. Поскольку пессимист — это хорошо информированный оптимист, описываю я типичные проблемы.

Не нужно настраивать себя, что вот всё плохо и нижесказанное обязательно со мной произойдет (может и нет). Но знать о ямах, что могут встретиться на дороге полезно — можно будет их обойти. Сразу отмечу, что пишу я, во-первых, о работе — не о бизнесе, а во-вторых, о работе в Украине. В других странах может быть по-другому. Чтобы было понятнее, буду проводить аналогии с работой слесаря на производстве. Ведь программирование есть не что иное, как создание, ремонт и эксплуатация программного обеспечения. С другой стороны, хочу, чтобы мне хоть раз в жизни пригодились «заводские» дисциплины, которые программистов заставляли учить в Национальном университете кораблестроения.

Итак, начнем пожалуй.

Допустим, некто ищет работу и получил несколько офферов. Что выбрать? Универсального ответа не существует, как его нет и на вопрос: «Какой автомобиль мне купить?». Давайте пройдемся по возможным типам компаний на украинском рынке и попробуем определиться, что кому подойдёт.

Иллюстрация Ульяны Патоки

Маленькая аутсорсинговая компания

— Почему вы ушли с предыдущего места работы?
— Компания переехала, и мне не сказали куда.
© на собеседовании

Собрались однажды три однокашника и решили открыть своё дело. Вначале апворк, потом нашли одного-двух клиентов, и пошло-поехало. Работу свою они знают, клиент доволен — пришла пора расширяться.

И тут оказалось, что гуманитарные предметы в отечественных вузах преподают ещё хуже, чем программирование. Философию, психологию и педагогику путём переписывания учебника, менеджмент — в лучшем случае на примере обанкротившегося в начале 90-хколхоза «Дурь Ильича». Так что постигать премудрости бизнеса приходится на практике, набивая всевозможные шишки и одновременно накапливая жизненный опыт. Вот список самых распространенных бизнес-ляпов. В той или иной степени ими грешат все новообразованные конторы.

• Невыплата или задержка зарплаты, невыполнение обещаний. Ну не понимают люди, что репутация — самое важное в бизнесе. Но ничего, жизнь быстро научит.
• Автоматический перенос своей психологии на чужую: я готов программировать с утра до ночи и соискатель тоже готов. Я понял задачу — и работник понял.
• Вера в свою исключительность, максимализм: в мою чудо-фирму я возьму только супермотивированных и пассионарных специалистов. Как ты не готов неделю делать тестовое задание без всяких гарантий? Нет... такой работник не нужен!
• Общая неорганизованность и бардак. В одной фирме, где я работал много-много лет назад, при переезде забыли нанять в новый офис уборщицу. Пол не подметался три месяца (!!!), пока арендодатель не поставил вопрос ребром: уборка или на выход!

Кому подойдет такая работа? Правильно: студенту последних курсов программистской специальности. Что-то умеет, уже писал приложения «для себя», но коммерческого опыта (за который платят) мало либо нет вообще. Куда-то получше его вряд ли возьмут, а у вышеописанных товарищей выбора нет — денег поначалу не густо. Да, могут кинуть с последней зарплатой. Может статься ещё веселее: в понедельник приходишь на работу, а дверь закрыта. Подождал-подождал, пошёл узнавать и услышал: «Ваш начальник в субботу забрал вещи и отдал ключи». Такое случилось с одним из знакомых. Что это было, он не знает до сих пор.

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

У работы в маленьких компаниях есть ещё один плюс: их никто не знает.

Появляются и уходят в историю очень часто, поэтому врать в резюме можно не особо стесняясь: проработали год — пишем два, дописываем в резюме технологии, с которыми может и не работали, но читали книжки. Эйчар более серьезной конторы не станет звонить в «Три хлебных корочки»: «Что там джуниор Вася, работал у вас с Docker или только слышал о нём?».

И даже если оттуда уволили за плохую работу, никаких последствий для карьеры не будет. Ну ушёл ты из фирмы «Рога и копыта», никого не убил, ничего не украл и ладно — других дел по горло, чтобы ещё джуниора какого-то пристально проверять. Проведу аналогию, допустим, на завод принимают молодого слесаря. Напильник в руках держать умеет, не пьющий, приводов в милицию нет и особых проблем со здоровьем тоже. Станут в отделе кадров докапываться, что там произошло у него в маленькой мастерской и почему он оттуда уходит? Нет. «Хочу работать на большом заводе, расти профессионально, иметь спецодежду, положенный по закону отпуск, получать аванс и зарплату первого и пятнадцатого числа, без задержек. Я слышал у вас это всё есть», — такой ответ идеально подходит. Кроме него на работу устраивается единовременно человек 20. Собирать досье на каждого, как в контрразведке? Ага-ага, болты во время скрупулёзных проверок кто будет точить? Люди сейчас нужны — не через два года.

Гиганты рынка

«Умные нам не надобны, надобны верные» © Аркадий и Борис Стругацкие, «Трудно быть богом»

Их отцы-основатели начали работать ещё в 90-х,прошли огонь, воду и медные трубы, настроили процессы, отточили найм, поэтому бизнес цветет и пахнет. Озаботившись прибылью не только теперешней, но и думая стратегически, гиганты вкладываются в образование: создают курсы с последующим трудоустройством. Одна беда: конкурс на одно место больше, чем в космонавты, поэтому совсем без опыта, скорее всего, не возьмут. Количество мест на курсах ограничено — отбирают лучших. А так для людей уровнем до синьора гиганты полезны.

Всё вроде бы хорошо, но где ложка дёгтя? А вот она: лидеры рынка сами ничего не разрабатывают — только предоставляют персонал для иностранных фирм.

Соответственно, им важно чтобы:

1. Заморский работодатель был доволен, то есть чтобы не сказал: «Этот Василий мне не подходит — несите следующего».
2. Разница между расходами на человека и доходом была максимальной.
3. Тратиться на найм как можно меньше. То есть чтобы на одном месте работник держался подольше и не воротил нос от устаревших технологий или переработок.

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

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

Ещё пример, уже из моей биографии. Сейчас без проекта. Создание новых языков встречается редко, поэтому если предлагают, то разговариваю и о другой работе. В одном из лидеров рынка у меня с менеджером произошел такой диалог.

ПМ: Работа состоит в том, чтобы переписать какую-то подсистему банка с совсем древней технологии на Java 8 + servlets (то есть устаревшим этот код становится в момент создания). Зачем это делать? Потому что кто-то на стороне клиента так решил. Ещё у нас бывают разные митинги. Необходимость тебе там присутствовать сомнительна, но заказчик требует, чтобы были все. Денег средненько: по рынку для разработчика, но не выше. Будет ли комфортно работать в этом проекте?

Я: Программирую за деньги. Если мы договоримся, буду выполнять свою часть контракта.

Приходит отказ: «У Владимира отсутствует другая мотивация, кроме финансовой — не подходит».

И я прекрасно понимаю ПМ’а. Он же не может сказать: «Владимир, конечно, опытный разработчик, умеет не только код писать, но выяснять требования, думает о проекте в целом, а не так, чтобы сделать вот эту задачу и хоть трава не расти. И вообще, знает математическую лингвистику! Но, возможно, понадобится поработать на выходных. Он фрилансер, почти бизнесмен. Бесплатно перерабатывать не привык и откажется. Мне объяснять заказчику, почему все другие согласны овертаймить бесплатно, а Кожаев — нет. Потом есть не нулевая вероятность, что ему предложат за узкие знания денег в два раза больше. Повысить аж настолько я не смогу, даже на время, пока не найду нового, ведь бюджет не резиновый. Он свалит, а я должен придумывать причину, по которой я не удержал на проекте хотя и немного строптивого, но нужного нам программиста. Решать, кем его заменить, за короткий срок. Поэтому поищу-ка я пусть не такого опытного, зато послушного и без претензий».

Возвращаясь к нашему слесарю, давайте подумаем: стоит брать на опиливание типовой детали #1 слесаря высокого разряда, умеющего шлифовать лопатки турбин? Кто не в курсе, работа это сложнейшая и очень ответственная. Чуть оплошаешь — и турбине конец. Специалисты даже собственное тавро имеют, мол, шлифовал такой-то. Будет ли такой слесарь делать все, что скажут, в условиях далёких от идеальных? Можно его при необходимости запрячь на бесплатный субботник? Не скажет ли он, мол, мне за это не платят, и пойдет пиво пить?

Есть ли в лидерах рынка проекты, где требуются знания выше среднего? Да, но платят за них похуже, чем, скажем, за работу на банки с легаси-технологиями — не их профиль. Опять же мне недавно предлагали разработку трансляторов с одного языка программирования на другой. И в той же конторе банковский проект за сильно больше денег. Напирали: «Работа ну очень интересная! Разовьёт вас профессионально. Может, вы подумаете?». Когда выяснилось, что я уже написал таких трансляторов с десяток, для меня это рутина, что, возможно, это их разработчикам интересно у меня поучиться, рекрутерша погрустнела.

Выходит, получение новых знаний выше какого-то уровня не имеет смысла? Нет ведь, есть...

...Продуктовые и узкоспециализированные компании

Занимаются развитием одного, реже нескольких продуктов либо продают консалтинг в узкой области. Поэтому по оплате они не ограничены внешним рейтом (ради хорошего человека могут временно и в минус уйти) еще и заинтересованы в высокой квалификации программистов. Чем выше, тем лучше. Это всё плюсы, а минусы?

Дело в том, что для таких фирм лояльность важна ещё больше, чем для аутсорсинга. И не потому, что бюджет ограничен. Причина другая: их товар — экспертные знания разработчиков. Например, занимаетесь вы разработкой SIP-мессенджеров или развиваете OLAP-систему. Можно найти в одночасье специалиста с такими знаниями? Нет! Ещё хуже, если это архитектор, такого только готовить внутри компании. Причем несколько лет! Оплачивать конференции, давать пробовать разные подходы, терять на архитектурных просчетах. А как вы думали, не ошибается тот, кто ничего не делает. Особенно если речь об учебе.

И представьте, человек, которого вы натаскивали, увольняется. Сколько потеряно денег? Вот именно!

Поэтому в такие конторы стараются брать тех, кто очень хочет работать именно здесь. Им должно быть важнее всего заниматься любимым делом, и этим делом должен быть продукт или предметная область компании. На зарплату, если хватает на жизнь, наплевать! Хотя денег там обычно выше среднего по рынку. Знаю, для многих это звучит музыкой, но не для всех. С возрастом и опытом любая работа становится просто работой, без сентиментов. Ну будет твоё имя где-то в конце списка повлиявших на проект разработчиков, может, в середине даже. И что?

Вот вам пример: разработка культовой игры «Казаки». Вы помните, кто там отвечал за искусственный интеллект персонажей, игровые стратегии? Между прочим, добиться плавного повышения сложности уровней — задача тяжёлая. В условиях постоянной нехватки времени разработчику небось приходилось забить на личную жизнь и на хобби — буквально не спать ночами. А выхлоп какой лично для него? Платят, возможно, чуть больше, но стал ли он миллионером? Или, может, его узнают на улицах? Кричали женщины «ура!» и в воздух чепчики бросали? Не бросали!

Лет пятнадцать назад я ещё был таким вот восторженным идеалистом: нам хлеба не надо, работу давай. Сейчас лапша с ушей спала. Хочу просто денег и не слишком упахиваться в процессе их заработка.

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

Если вспомнить слесаря, можно сравнить с работой на экспериментальном заводе. Платят неплохо, но долго учиться, и если этот завод закроется, то на другом придется начать всё сначала.

И остаётся фриланс.

Фриланс и удалённая работа

«Не звоните нам, мы сами вам позвоним» © из собеседования актеров в Голливуде

Подходит только для опытных, которые могут не только выполнить задачу, но и рассказать заказчику, что именно и каким образом нужно сделать. При том так, чтобы он захотел заплатить и сделал это. Начинающим во фрилансе не место, зато опытный специалист может работать из любого места и сколько хочет, был бы интернет. Летом часть времени я живу на юге, и отпрашиваться у менеджера мне не нужно. При этом потолок оплаты выше, чем в офисе — с галерой-то не надо делиться. Технологии тоже какие хочешь. К примеру, я разрабатываю компиляторы, трансляторы, парсеры, IDE и прочее Rocket Science. Такой работы на Украине очень не много, всё больше CRUD и формошлёп.

Но есть и ложка дёгтя. Во-первых, проекты нужно искать самому и по окончанию никаких гарантий, что будет другая работа. Во-вторых, за работу ты конкурируешь на глобальном рынке труда. И внезапно оказывается, что для решения распространенных задач типа написать мобильное приложение или создать бэкенд на Java, или сварганить сайт, на Upwork можно найти исполнителей гораздо дешевле украинского рынка труда. Предположим, ты программист Java. Знаешь спринг, хибернейт, базы данных, работал с докером и ещё можешь пилить фронтенд.

В Киеве за такого орла-мужчину томные девы с чарующим размером груди будут буквально драться, лишь бы оффер принял. Но на сайтах фриланса гордых Full Stack разработчиков из Пакистана, Индии, Вьетнама etc больше, чем в Бразилии обезьян, и работать они согласны по очень сходной цене. На более-менее интересное предложение может откликнуться до тысячи (!!!) разработчиков. Готовы к такому конкурсу? Милости прошу во фриланс!

Можно, конечно, как я изучить совсем уж заумную штуку типа математической лингвистики, тогда конкурентов у вас не будет. Но и тут не без подвоха: как думаете, многим нужны новые языки программирования? То-то же! Я или нужен, тогда походи по рынку и поищи дешевле, либо не нужен вообще. Так что простои у опытного фрилансера — нормальное явление: нужно иметь кубышку на три-шесть месяцев. Для того чтобы перерывы были поменьше, необходимо шевелиться: писать статьи, выступать на конференциях и так далее. Вы думаете, зачем я эти статьи пишу? Потому что добренький — ага, сейчас!

Есть ещё одна проблема: сложную работу многие предпочитают делать у себя под боком. Я как-то подался на вакансию разработчика в дружественную компанию. Они читают мои статьи на английском, иногда обращаются за советом, но ... вакансия в Германии. Хочешь, говорят, приезжай. Из Украины мы не можем, чтобы ты работал: заказчики хотят наличия специалиста в их стране.

Более того, если вы захотите вернуться в офис, фриланс может оказаться минусом. Был такой случай: пригласили меня на работу, найдя по статьям. Поговорили, вроде всё здорово. Но потом тот, кто меня нанимал, пишет: «Извини, тебя взять не можем. Главный начальник против человека с длительным фриланс-опытом». Да, понюхавших свободы не все хотят — слишком уж независимые. Это ещё называют отсутствием командного духа, читай: прогнуть на бесплатные овертаймы нельзя.

Наш опытный слесарь может открыть свою лавочку и выбирать: чинить замки, прочищать унитазы или делать оптику разного рода. Второе, конечно, поинтереснее, в том числе и финансово, но это, если найдешь клиентов.

Ну что ещё можно: открыть свой бизнес, стать менеджером или уехать за границу. Но это уже совсем другая история.

[Кирилл Захаренков до 2010 года работал как Embedded Software/Hardware Developer. Соавтор двух американских патентов. Последние 10 лет занимается управлением людьми. Иногда кодит в интересных проектах. В данный момент работает СТО в компании Dynamo Development,Іnc.Один из создателей украинского стартапа «Мій Дім Онлайн».]

Во второй части статьи поговорим об анализе результатов принятых решений, о состоянии членов команды и утомлении, о режиме работы и личном времени, о планировании и рисках. Первая часть — здесь.

Что ж, приступим.

Чтобы построить успешный бизнес, нужно принимать правильные решения. Чтобы принимать правильные решения, нужен опыт.
Чтобы приобрести такой опыт, нужно некоторое время принимать неправильные решения.
Радислав Гандапас

Об анализе результатов принятых решений

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

Причины принятых решений должны быть четко понятны всем членам команды.

Случаются исключения из этого правила, связанные с коммерческой тайной и другими аспектами бизнеса, но они должны быть исключениями, а не постоянной практикой.

Иногда мы настолько увлечены доказыванием своей правоты, что не способны воспринимать важные замечания и аргументы окружающих.

Забавная история произошла с моим коллегой во время совещания с нашими партнерами из Канады. Мы обсуждали возможности удешевления аппаратной части одного из наших продуктов. В ходе дискуссии было решено удалить из электронной схемы элементы защиты, которые принято применять в подобных случаях. Таких компонентов было много, и их стоимость, вместе со стоимостью монтажа, переваливала за доллар. На партии в миллион устройств экономия могла быть очень существенной. Говоря откровенно, во многих частях схемы установка таких компонентов была скорее перестраховкой.

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

Каждый член команды должен быть готовым выслушать и принять к исполнению точку зрения, отличную от собственной, если она принимается большинством экспертов команды.

Какие бы методики мы ни применяли, как бы ни старались, к сожалению, не все наши решения будут правильными. Но стоит ли наступать на одни и те же грабли несколько раз?

Результаты принятых решений должны анализироваться командой для совершенствования процессов.

Ретроспектива, описанная в scrum guide, может служить хорошим примером извлечения уроков из предыдущего опыта.

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

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

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

Может ли эффективно работать сотрудник, задерживаясь вечером в офисе в день рождения своего ребенка? В моей коллекции есть интересная переписка менеджера с разработчиком. Я внес коррективы в текст, чтобы сохранить приватность авторов, но смысл остался без изменений:

О состоянии членов команды и утомлении

Состояние членов команды должно постоянно приниматься во внимание руководителями и другими членами команды. Сотрудники, которые сталкиваются с ухудшением здоровья или психологического состояния, не могут эффективно выполнять работу.

Психологи упоминают об интересной зависимости, полученной в ходе экспериментов над животными. Еще в 1908 году учёные определили, что существует оптимальное значение мотивации, которое приводит к максимальной эффективности выполнения задания. Было установлено, что средняя интенсивность мотивации (разряды электрического тока) приводит к наилучшим результатам при прохождении лабиринта «братьями меньшими». Повышение же мотивации ведет к нежелательным эффектам, таким как волнение, напряжение, стресс. Эмоциональное напряжение может способствовать решению задачи, а может привести к совершению серьезных ошибок.

Всем людям свойственно уставать при выполнении работы. Утомление вносит временный дисбаланс в функционирование различных систем организма, и наша работоспособность снижается. Тем самым организм дает нам понять, что ресурсы исчерпываются, и нужно отдохнуть для восстановления запасов энергии. Утомление является одной из защитных реакций организма, предохраняющих его от истощения. Усталость имеет свойство накапливаться и приводить к состоянию переутомления. Переутомление уже граничит с патологическими состояниями, которые могут наносить серьезный вред здоровью — не только психическому, но и физическому. Нарушения сна, раздражительность, слабость, головные боли, ощущение разбитости после отдыха свидетельствуют о переутомлении. Советский психолог Константин Константинович Платонов (1906–1984)выделил четыре степени переутомления.

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

«Бегемотик молча слушал его, не перебивая, но не скрывал своего непонимания».
Сказка про синенького бегемотика и Осень.
Дорфман Аня

Бегемотик непонимания порой не только пробегает между членами команды — иногда он просто нагло пасется на наших совещаниях и топчется в наших постановках задач. Зачастую сотрудники стесняются уточнять задание или совершенно иным образом истолковывают его. Результатом является много работы, сделанной впустую. Надо отдать должное и менеджерам, которые не отстают в вопросах генерирования путаницы, а порой и гордо возглавляют процесс. Вот один из ярких примеров «лаконичной» постановки задачи, найденный мною в корпоративной jira: «Добавьте места между линией. Кнопка одна в одном стиле, другая в другом. Жёлтым красиво нарисуйте, как в программе — заголовок и значения».

Велосипед изобрели до нас. Нам просто нужно взять на вооружение простые правила и следовать им.

Правильность понимания полученной информации должна подтверждаться получателем в деталях, если существует риск неоднозначного толкования данного вопроса.

Хорошим примером могут служить правила радиообмена, принятые в авиации, когда указания диспетчера должны быть в точности повторены пилотом.

В нашем арсенале есть такой действенный инструмент, как meeting minutes (заметки о совещании). Если мы опишем или сообщим другим способом о том, как мы поняли задачу, то у наших коллег будет возможность вовремя поправить нас в случае неверного истолкования. Не стесняйтесь в конце обсуждения говорить: итак, я понял вас следующим образом. Все это приведет к существенной экономии времени и ресурсов.

Если вы ставите задачи подчиненным, то 4 или 5 лишних предложений с деталями и пояснениями могут потребовать у вас дополнительные 10 минут. Но эти 10 минут могут сэкономить сутки в масштабах проекта, если ваша команда работает в разных часовых поясах.

Распределенные команды, работающие в разных часовых поясах, должны координировать действия в согласованные временные интервалы для эффективного уточнения заданий, проведения всех необходимых согласований, планирования, чтобы избежать суточных задержек.

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

Недостаток информации не является причиной моментального отказа от выполнения задачи. Сотрудники должны приложить усилия, попробовав разобраться в вопросе, а в случае необходимости — запросить уточнения.

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

О планировании и рисках

"«...Есть известные известные — вещи, о которых мы знаем, что знаем их. Есть также известные неизвестные — вещи, о которых мы знаем, что не знаем. Но еще есть неизвестные неизвестные — это вещи, о которых мы не знаем, что не знаем их».
Дональд Рамсфельд

Многие из наших коллег жалуются на плохое описание и неточную постановку задач. Пока я не ставил задачи своим подчиненным, я также удивлялся, сколько не учтенных поначалу ситуаций всплывало во время работы по предоставленным мне техническим заданиям. Как хорошо бы мы ни поработали над ТЗ, в задании всегда существуют не известные нам составляющие-риски. Риски — это, в первую очередь, неопределенность. PMI (Project Management Institute) приводит интересную зависимость вероятности возникновения рисков от времени выполнения проекта. Такая зависимость справедлива и для отдельно взятой задачи.

При выполнении задания мы все больше и больше углубляемся в его суть. Открываются детали и кейсы, о которых мы не подумали в самом начале. Нам приходится принимать решения, вносить коррективы по ходу работы. Конечно же, с рисками нужно работать на этапе создания требований, но это не гарантирует, что все было учтено на 100%. Чем лучше мы проведем декомпозицию (разобьем задачу на более мелкие составляющие), тем лучше мы продумаем каждую подзадачу в отдельности. Мы можем с определенной степенью вероятности оценить риски, если нам известны неизвестные вещи. Но, к сожалению, мы сталкиваемся с ситуацией, когда неизвестные вещи нам неизвестны.

Каждый член команды должен понимать, что постановка задачи всегда является неполной. Всегда открываются новые обстоятельств и вопросы, возникшие в ходе выполнения. Сотрудник обязан уточнять детали и получать разъяснения у лиц, владеющих необходимой информацией, а эти лица обязаны такую информацию предоставить. Каждый менеджер понимает, что первоначальная оценка не является точной.

Все существующие техники управления основываются на цикле Деминга. Эту простую модель называют еще моделью PDCA: (Plan) Планируй, (Do) Делай, (Check) Проверяй, Act (Воздействуй). Присмотритесь внимательно, и вы поймёте, что так или иначе ваша команда взаимодействует согласно этому принципу. К большому сожалению, обычно мы уделяем больше внимания Do (Делай) и Check (Проверяй) — и существенно меньше Plan (Планируй) и Act (Воздействуй).

Любому действию предшествует мысль, писал Ральф Уолдо Эмерсон.

Важно, чтобы каждый член команды понимал: задача должна быть оценена по времени выполнения и сложности, должны быть проверены возможные риски до начала работы. Если в ходе уточнений задания первоначальная оценка изменяется, то об этом нужно поставить в известность всех, кто причастен к выполнению задачи, а также руководителей команды и проекта.

Порой задания кажутся нам непонятными и неподъемными. Хороший совет, как поступать в таком случае, дал еще Марк Твен: «Секрет того, чтобы продвинуться вперед, заключается в том, чтобы начать. Секрет того, как начать, заключается в том, чтобы разбить свои сложные неподъемные задачи на маленькие и управляемые, а затем начать с самой первой из них».

В современном менеджменте такой метод называется декомпозицией задачи. В своей методологии Get Things Done (сокращённо GTD), Дэвид Аллен рекомендует для начала определить следующее действие, если оценить весь объемный проект или большое задание слишком сложно. Результатом такого первого действия и может стать декомпозиция задачи и ее оценка.

Каждый член должен быть ознакомлен с планом работы команды, оценкой задач по времени и возможными рисками. Планирование и оценка по времени должны включать оценку возможных рисков и учитывать возможности команды и графики работы сотрудников.

Говоря о графике работы, мы уже рассматривали случаи работы сотрудников в дни знаменательных для них дат. Во избежание излишней напряжённости было бы правильно вести командный календарь важных для сотрудников событий с тем, чтобы принимать их во внимание при планировании деятельности команды.

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

Если требуете от людей оставаться на связи 24 часа в сутки — не беспокойте их по пустякам, иначе однажды, когда вам понадобится реальная помощь, вы окажетесь с проблемой наедине.

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

Режим работы каждого члена команды должен быть известен коллегам, а в случае его изменений команду нужно оповестить как можно раньше — как только это позволит ситуация.

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

Каждый член команды должен по запросу коллег сообщать статус выполнения поставленных перед ним задач. Оповещение коллег о завершении выполнения задачи должно быть осуществлено настолько быстро, насколько это возможно.

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

Каждый член команды должен четко сообщать о намерениях и целях, а также ставить в известность коллег при отклонении от оговоренного плана.

«Один в поле не воин».
Старинная пословица

19 июля 1989 года пилоты рейса 232 United Airlines столкнулись с непростой ситуацией. Из-за технической неисправности было невозможно выполнять развороты воздушного судна. Приземление в таком состоянии самолета грозило серьезной катастрофой. Но по счастливому совпадению, данным рейсом летел в качестве пассажира инструктор авиакомпании. Он и предложил свою помощь экипажу, когда почувствовал, что что-то идёт не так. Капитан принял помощь опытного летчика Денниса Е. Фитча, который находился не при исполнении. Деннис управлял тягой двигателей во время аварийной посадки и стал четвертым членом экипажа, без которого пилоты вряд ли смогли бы посадить самолет. В катастрофе погибли 111 человек, но еще больше оказались спасены. В то время компания United Airlines уже была в числе первых, кто применял crew resource management. Описанный случай может считаться документальным подтверждением эффективности этой методологии.

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

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

В моей практике был случай, когда один из сотрудников год сидел на неудобном стуле, из которого выпирал неудачно вставленный болт. Он заявил об этом во время ежегодного ревью, когда его прямо спросили насчет комфорта на рабочем месте. Вместо того чтобы решить проблему за считанные минуты, мы продолжаем, пользоваться неисправным или неудобным инструментом или бьемся лбом о глухую стену в поисках решения. Вместо того чтобы спросить коллегу, который поможет выйти из глухого угла, потому что уже решал подобную задачу, мы продолжаем настойчиво мучить себя.

Традиционно в конце второй части предлагаю вашему вниманию табличку с хорошими и плохими практиками. В следующей, заключительной, части мы поговорим о приоритетах, работоспособности и эффективности работы.

[Михаил Кашкин — Python разработчик и автор курса «Практический Python с нуля»]

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

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

Точка отсчета

Мне всегда нравился Python. С первых дней знакомства с языком сообщество очень помогло в изучении, документации, поиске работы и заказов. Как-то само собой получилось, что я стал помогать в ответ сообществу. Постепенно оброс обязательствами в этой области, организовывал PyCon и локальные события в разных городах. Согласно статистике, около 70% людей, которые приходят на конференции, называют себя новичками. Мне часто задавали вопрос: с чего начать. Сам я начинал с учебников, поэтому рекомендовал книги или курсы.

Больше года назад я закончил сотрудничество с одной компанией, после которого понял, что выгораю. Физически плохо становилось от мысли выйти на очередной звонок. И я взял паузу в карьере и начал писать учебник по Python’у. Когда была дописана половина, понял, что надо что-то с этим делать. Сначала решил опубликоваться просто как обычный автор. И я попробовал связаться с издательствами. Выхлоп от публикации книг не очень большой, особенно если сравнивать со средней зарплатой программиста. Заработок от продаж более-менее успешной книги составляет пару тысяч долларов. Звезды зарабатывают больше, но таких мало. Издатели платят переводчикам несколько сотен долларов за книгу, это маленькие деньги. Бюджетов, чтобы спонсировать что-то существенное кем-то неизвестным, у издателей нет.

Параллельно со мной общалась менеджер из Udemy и предлагала сделать свой курс. Я решил посмотреть в эту сторону. И, собственно, с этого момента начинается мой рассказ.

Консультации по карьере

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

Это сильно отрезвляет.

Я совершенно спонтанно записал видео — разбор резюме и собеседования на позицию начинающего разработчикасо знакомым, и оно сильно взлетело. А потом встретился еще с несколькими выпускниками разных курсов, которые согласились пообщаться лично. То, что я узнал, вызвало недоумение, и мне захотелось разобраться лучше. Так начали складываться части пазла, хотя в целом картина еще была непонятна.

Мне было интересно узнать, какие вопросы возникают у тех, кто интересуется обучением в принципе, и я предложил записаться на консультации по карьере. То есть провести тестовое интервью и ответить на вопросы собеседников. Открыл свой календарь для записи через простую формочку — и созванивался с людьми каждую неделю во вторник и четверг несколько недель подряд. Я провел около 30 интервью с разными людьми. В большинстве своем, это открытые и честные ребята, которые хотят свободы, счастья и стабильности. Это не ленивые и глупые монстры, какими их любят выставлять в комментариях. Я могу рассказать множество историй людей, которые честно делали свою работу, а потом утыкались в полоток в своей профессии и понимали, что перспектив нет. Они трезво смотрят на жизнь и готовы меняться. Не во всех отраслях есть перспективы. В айти ситуация получше. Но я говорю не об отрасли в целом, а конкретно про деньги, уровень риска и стабильности.

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

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

Можно ли научиться онлайн

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

Неожиданно откликнулся Яндекс. Да, я знаю, какой у компании имидж, поэтому очень аккуратно вышел на переговоры с их представителем. Руководитель Яндекс.Практикума меня очаровал, это умный и приятный задрот в лучшем смысле этого слова. Он верит, что образование может поменять что-то в этом мире к лучшему. И в течение нескольких месяцев я сделал для них свою часть образовательного курса по Python.

Самое интересное здесь — понять: можно ли действительно научить людей программированию онлайн? Если вам этот вопрос кажется праздным, то передо мной он стоял остро. Инфобизнес сформировал стойкий привкус обмана вокруг любого образования. С другой стороны, многие мои знакомые проходили курсы на Курсере и остались ими довольны. По себе судить я не стал.

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

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

Когда я наконец-то увидел код, написанный студентами курсов, которые я помогал создавать, то был искренне поражен. Есть «курсы с нуля», которые проворачивают такой трюк: находят ребят, сильно сомневающихся в себе, но долго учащихся самостоятельно. Отбирают на начальном тестировании тех, кто уже достаточно готов. Читают что-то полтора месяца в стиле «выучи программирование за 21 день», а потом присваивают себе успехи студентов.

Я же видел код, который писали ученики после первых этапов. И потом — код, который они же писали после прохождения лекций. Это был хороший и стабильный код, не хуже того, что встречается в разных компаниях. И это спустя четыре месяца с начала обучения! Прежде всего, говорю о своей фазе курса «Практикума». То есть люди действительно показали крутой прогресс.

Этот факт меня очень обрадовал и воодушевил.

Чего хотят работодатели

Сейчас я уже понимаю, что для того чтобы выучиться, нужны две вещи: получать от этого удовольствие и регулярно этим заниматься. Я получил практическое подтверждение того, что обучение само по себе работает.

Осталось найти ответ на второй главный вопрос: как студенту после окончания учебы устроиться на работу?

Надо прояснить один момент: вакансии есть, их много, и они закрываются не за один день. Есть компании, у которых существуют позиции для начинающих разработчиков. Но судя по аналитике Джина, огромная пропасть между теми, кто уже написал в своем резюме, что он джун, и теми, кого на самом деле ждут работодатели. Отзывов на вакансии очень много.

Поэтому возник еще один исследовательский проект. Мне повезло получить доступ к этому исследованию, пусть в необработанном виде. В документе были стенограммы опросов 30-40крупнейших компаний, нанимающих Python-разработчиков. Да, некоторые выставили заоблачные требования к джунам. Но большинство просили вполне адекватного.

Так была сформирована карта навыков, которые ожидались от соискателя. Я подробно расписал каждый пункт, и получилось больше 7 месяцев обучения без больших перерывов с лимитом времени 5 часов в неделю.

В этот момент стало понятно, что мой учебник, с которого я начал, отвечает лишь небольшой части реальных требований рынка. И я принялся составлять новую карту развития:

• Синтаксис языка
• Фреймворки
• Базы данных
• Портфолио
• Софт-скиллы

Если вам интересно почитать обо всех пунктах подробнее, то просто заходите на сайт, там есть описание каждого.

Это был поворотный момент, в который стало понятно, какой объем информации нужен, чтобы честно выполнить свою работу обеим сторонам:

• ученику, который хочет устроиться на работу и приносить пользу работодателю;
• преподавателю, который готовит студентов.

Теория обучения

Причина, по которой получилось у Яндекса, мне была не совсем понятна. Поэтому я обратился к теории обучения и когнитивистике. Мне очень помогли два близких человека.

Конечно, это моя жена, которая бесконечно верила в меня и мягко напоминала, что этот весь путь я проделываю не только для себя. В процессе решения собственных задач она увлеклась когнитивистикой и подсказывала очень много полезного, что сильно повлияло на продукт. Благодаря ей после каждого урока мы добавили по небольшому опроснику. Оказывается, наш мозг устроен так, чтобы отфильтровывать всю поступающую информацию: она кладется в «быструю» память, чтобы не тратить ресурсы на то, что потом не будет иметь никакой ценности. Но если по пройденному материалу задать хоть один вопрос, то мозг пропускает вопросы через «долгую» память. Такой простой трюк приводит к тому, что мозг запоминает материал на пару десятков процентов лучше. Любой, даже простой вопрос. И таких нюансов множество.

Мой папа был учителем, но мы никогда особо не обсуждали мой проект. Да я и не совсем представлял все детали. В марте у папы случился инфаркт, его положили в больницу. И он несколько дней ничего не говорил, чтобы нас не пугать. Плюс еще пандемия, а мы ждали рождения дочки. Как только я узнал о его состоянии, сразу же приехал в больницу, и мы смогли некоторое время пообщаться в палате. Я рассказал о том, чем сейчас занимаюсь. Сказал, что мне не совсем понятно, как вообще работает обучение и есть ли у меня какие-то особые навыки — или преподавать может любой студент, который взял в руки учебник. Папа дал мне ответы на эти вопросы.

С точки зрения теории обучения, для того чтобы выработать навык, нужно 3 компонента:

• Теория. Это то, что подается в учебниках, и то, что, оказывается, не является самой важной частью обучения. Это необходимо, но ценности представляет столько же, сколько и распечатка документации.
• Практика. Вот это уже интереснее и важнее, и самая большая проблема онлайн-курсов — в том, что почти нигде нет практики.
• Экспертиза преподавателя. Это те люди, которые знают, куда ударить молотком, и которые прошли большой путь и могут отбросить лишнюю теорию или направить практику в нужном направлении.

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

Через день папы не стало. Поэтому я много раз прокручивал этот разговор в голове.

Постепенное погружение

Еще на этапе написания учебника я знал, что людей прежде всего интересует, как перейти к практике и как применять инструменты программирования. В одном волонтерском проекте я работал с девушкой, которая скачала какой-то курс и не могла продвинуться по нему. У нее были проблемы с тем, чтобы просто запустить код из редактора. Оказалось, в ее коде какие-то простые ошибки в синтаксисе. Новичку может быть сложно разобраться с такими вещами.

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

Поэтому у меня сразу было требование: иметь онлайн-тренажер, который позволяет выполнять код в браузере.

Я провел исследование разных образовательных систем и понял, что на рынке нет того, что мне надо. Поэтому почти сразу начал писать свою LMS (движок образовательного проекта). С тренажерами, домашними работами и разными вещами.

Что еще надо, чтобы устроиться на работу

Основной вопрос большинства людей — возьмут ли их на работу. И тут возникает интересный конфликт. Джунов не берут на работу, в том числе потому, что они не совсем понимают, как работать в команде, а не понимают, потому что не работали в команде.

Сейчас мне это кажется очевидным, но я ни разу не видел в программах обучения курсов уроков о том, как работать в коллективе. Как проходить собеседование или просто банально отстаивать свои границы. Мне бы хотелось работать с людьми, которые понимают такие вещи, поэтому я включил много софт-скиллов в свою программу обучения.

Одной из частых рекомендаций экспертов является предложение сделать несколько проектов на Github. Каждая ступень заканчивается практическим проектом и новым пунктом в портфолио.

Итог

Моя особенность в том, что я стараюсь все делать с большим погружением. Возможно, иногда это излишне, но пройдя этот путь, понимаю, что создание курсов — не такое простое дело, как кажется. Может быть, я слишком перемудрил. Сейчас определенно некоторые вещи сделал бы иначе, но я пока не на той стадии, чтобы давать советы по обучению.

Есть известное выражение: бизнес-консультации дают те, у кого не получилось построить собственный бизнес. Но это сильно обесценивает. Обесценивает те вещи, которые представляют угрозу. Не пытаюсь встать на защиту других школ или инфо-цыган, но тем не менее, присмотревшись к другим, я вижу, что преподаватели вкладываются — каждый по-своему. Врать окружающим сложно, и преподаватели действительно верят в то, чем делятся. Да и обратная связь прилетает очень быстро. Скорее, стоит задумываться о том, что много спроса на магию, а не на реальные навыки.

Лучший способ выйти из зоны комфорта — начать продавать. Это действительно больно — и, честно говоря, не рекомендую. Но если решитесь, то готов подсказать, что уже знаю.

Тем, кто решает, что лучше: «бесплатные» книги, торренты или платные курсы — скажу, что EdTech часто решает вопрос, как создать ощущение прогресса, а не обеспечить реальное продвижение. Это как лекарство, снимающее симптомы, чтобы подольше продавать услугу. Но для тех, кто готов развиваться, плохие учителя или системы не являются препятствием. Например, Курсера не дает практику, но студенты все равно получают знания и гордятся сертификатами.

Можно самому изучать теорию и искать практику. С третьей частью обучения — наставниками — сложнее. В теории, можно ходить на выступления или митапы. Но это ощутимо затратнее с точки зрения времени. Те, кто купят обучение, скорее всего, справятся быстрее — и займут ваше место, пока вы будете читать учебник.

Образование — это сервисный рынок: платите только тогда, когда получаете сервис. Отдельно информацию в отрыве от остального найти как раз несложно.

Надеюсь, мои наблюдения вам помогут.

[Кирилл Захаренков до 2010 года работал как Embedded Software/Hardware Developer. Соавтор двух американских патентов. Последние 10 лет занимается управлением людьми. Иногда кодит в интересных проектах. В данный момент работает СТО в компании Dynamo Development,Іnc.Один из создателей украинского стартапа «Мій Дім Онлайн».]

В заключительной статье (перваяи втораячасти уже опубликованы) поговорим о приоритетах, работоспособности и эффективности команды.

Жаль, подмога не пришла,
Подкрепленье не прислали.
Нас осталось только два,
Нас с тобою нае....ли.
Борис Гребенщиков

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

Влияние приоритетности заданий на эффективность работы

Каждый член команды должен знать приоритеты выполнения задач и быть готов к внезапному их изменению.

Если подробнее рассмотреть процесс работы над задачей, можно выделить несколько фаз:

• врабатываемость;
• компенсация (устойчивая работоспособность);
• субкомпенсация;
• утомление.

Врабатываемость представляет собой фазу, в которой ваша психика адаптируется к выполнению задачи, задаётся ритм работы, обрабатывается и аккумулируется необходимая информация. Длительность фазы зависит от того, чем человек занимался перед тем, как приступил к задаче, от его психического состояния и многих других факторов. В различных источниках приводятся разные цифры длительности — от 10 до 30 минут.

После врабатываемости наступает устойчивый режим работы, который называется фазой компенсации. Этот режим длиться в среднем от 1,5 до 4 часов.

Далее следует фаза субкомпенсации. Она характерна периодическим снижением активности и качества выполняемых работ. Длительность данного периода — от 10 до 30 минут.

Затем наступает утомление, когда организм уже не может восстановить первоначальный уровень работоспособности.

В ходе переключения на другую задачу специалист неминуемо проходит стадию врабатываемости. Это означает, что теряется продуктивность работы и время выполнения задачи возрастает.

Каждый руководитель должен осознавать, что частое изменение приоритетов снижает эффективность работы.

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

Однажды я решил проверить, сколько сообщений получаю в течение рабочего дня в различных чатах. Выбрал исключительно запросы, которые были обращены ко мне и требовали ответа в той или иной форме. В результате получил 74 сообщения.

Обращения в чатах в течение рабочего дня

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

Если хотите отвлечь коллегу от его занятия, убедитесь в том, что это действительно важно, и продумайте, какие вопросы могут еще возникнуть, чтобы задать их одновременно.

Если планируется обсуждение, хорошей практикой служит составление повестки дня для совещания. При подготовке списка вопросов вы уже продумываете их смысл и, возможно, сами предложите некоторые из решений. В этом случае ваши коллеги будут иметь достаточно времени, чтобы вникнуть в детали и подготовить более четкие ответы.

Часто члены команд работают над большой задачей, выполняя разные ее части параллельно во времени. Менеджеры проектов называют это fast tracking.

Хочется вспомнить бородатый анекдот по этому поводу. «Строительной компании поступил заказ на постройку тоннеля под проливом Ла-Манш. На презентации плана проекта землекопы сообщили, что для ускорения работы две команды будут рыть тоннель навстречу друг другу, чтобы встретиться в середине пути. На вопрос заказчика «А что будет, если вы не встретитесь?» исполнители ответили: «Тогда у вас будет два тоннеля».

Параллельная работа всегда сопряжена с увеличением рисков. Вероятность того, что исполнители закончат одновременно свои части, чтобы собрать их воедино, практически равна нулю. Кто-то обязательно не успеет к сроку. Если выполнение его задачи блокирует выполнение последующих, то неминуемо задержится срок и по всем другим частям.

Задачи сотрудника, от которых зависит выполнение задач другими членами команды, должны быть подняты в приоритете и по возможности выполняться в первую очередь.

В сети прочитал интересный факт: в старину у многих народностей длинные рукава считались признаком принадлежности к элитному классу. Обладатели такой одежды не занимались физическим трудом, а их руки не доставали до края рукавов. По этой версии и возникло выражение «не доходят руки», означающее, что нет времени или возможности сделать что-то.

Каждый проект обязательно содержит множество задач, до которых не доходят руки. Если приоритет этих задач будет оставаться по-прежнему низким, они никогда не станут завершенными.

Неспрочные задачи должны подниматься в приоритете по истечении определенного времени, чтобы к их выполнению дошла очередь.

Похожий принцип используют некоторые из операционных систем для диспетчеризации задач. Хороший совет дает Дэвид Аллен в своей книге «Как привести дела в порядок». Он предлагает применять к задачам правило двух минут, невзирая на приоритеты. Смысл правила состоит в том, что, если дело занимает менее двух минут, оно должно быть выполнено тотчас, а не отложено на потом. Понятие двух минут относительное. Вы можете определить для себя любой другой интервал времени в зависимости от текущей ситуации.

А что на практике

Традиционно в конце третьей части предлагаю вашему вниманию табличку с хорошими и плохими практиками.

Итог

В завершении хочу сказать, что не стоит рассматривать жизненные ситуации исключительно в контексте черного и белого/плохого и хорошего. Наш мир многогранен, сложен и состоит из палитры множества оттенков цветов. Открывая дверь нового дня, вы не можете полностью предугадать цепь событий, которые предстоит прожить. Это делает нашу работу и повседневную жизнь интересной. Каждая личность особенная. Общение с каждым человеком требует особого подхода. Пусть в вашей жизни всегда будет много положительных эмоций, интересных встреч, увлекательных путешествий и захватывающих задач, решить которые вам под силу.

Приглашаю к обсуждению материала в комментариях. Спасибо за ваше внимание!

«Кожен повинен бути самомотивуючою біологічною машиною
Євген Черняк, бізнесмен, ведучий YouTube-каналу Big Money

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

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

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

Ілюстрація Аліни Самолюк

Причини стагнації

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

Однотипні проєкти, проєкти з низькою якістю коду

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

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

Робота на фрилансі без команди

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

До того як прийти в OpenGeeksLab, я півтора року був фрилансером. Працював на проєкті, власником якого був житель Аляски. Золотий клієнт. Завжди вчасно розраховувався і ніколи не сперечався за відпрацьовані мною години. Проєкт був на популярному в ті часи MEAN-стеку із використанням бібліотечки Fabric.js. І якщо перший рік я ще пиляв фічі, грався з прототипним наслідуванням для побудови кастомних об’єктів у Fabric, розбирався, як під капотом працює AngularJS digest тощо, то останні пів року просто сидів і вигадував, що б то поліпшити.

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

Відсутність мотивації

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

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

Коли в спеціаліста є мотивація, він краще виконує завдання і цим полегшує роботу собі й навколишнім.

Професійне вигорання

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

Що робити в такій ситуації? Не панікувати. І читати далі.

Поради щодо розвитку

Ф̶а̶к̶а̶п̶и̶ ̶с̶т̶а̶ю̶т̶ь̶с̶я̶. У житті буває по-різному. Але людині під силу все змінити й вийти на якісно новий рівень.

Йди в ІТ, якщо справді любиш технології та хочеш вчитися

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

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

Тут стають у пригоді патерни, алгоритміка, архітектурні підходи. Все це добре допомагає у вивченні нового. А нове, своєю чергою, — це добре поліпшене старе.

Ініціюй ротацію чи зміни компанію

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

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

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

Візьми тайм-аут

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

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

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

Зміни посаду

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

Наприклад, девелопери переходять у бізнес-аналітику, щоб спілкуватися як з технічними, так і з нетехнічними фахівцями.

Я за освітою системний аналітик. І це допомогло мені стати програмістом, який вміє ставити гарні питання.

Розважайся

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

Розвивайся

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

Я у вільний час колупаю сервер, граюся з технологіями. Ще, наприклад, пройшов курс з DevOps на Udemy. Він був про те, як працює Docker і оркестровка. На мітингу поділився здобутими знаннями з колегами. Наразі в нашій компанії всі проєкти йдуть по CI/CD pipelines. Такий рутинний процес, як деплой, автоматизований на всіх проєктах, і його може зробити будь-який розробник.

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

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

Комунікуй

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

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

Обирай сильніших за себе

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

Бери складні проєкти, пробивайся в команду людей, які розумніші за тебе. У розробці не можна стояти на місці, бо, поки ти зупинився, ком’юніті пише нову версію твоєї улюбленої бібліотеки.

Так, це складніший шлях, але й живий досвід і якісно новий результат.

Спробуй менторство

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

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

Проявляй ініціативу грамотно

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

Я пішов в OpenGeeksLab фронтенд-розробником. Писав на Angular і сів на великий проєкт. Якось колишній CTO компанії зібрав усіх нас на тімбілдинг і розповів про мікросервіси. Мене це зацікавило. За кілька тижнів зайшов проєкт з мікросервісами. Мені довелося дуже швидко опановувати, що це таке, як взаємодіють сервіси, як працює AWS, що таке оркестровка і Docker swarn. Після того, як з усім розібрався, справа пішла, і я потихеньку перекочував у серверну інфраструктуру.

Я довгий час підкидав ідеї щодо оптимізації процесів розробки, працював з будь-яким стеком, який траплявся. Зайти на PHP? Ок. Фронт на jQuery? Ок. З цього моменту розвиватися стало простіше. Наприклад, багато фронтенд-розробників знають бібліотеку Redux Saga, але мало хто знає, що є Saga Design Pattern, а ще менше — що його можна застосовувати на бекенді.

Висновок

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

Ніхто не каже, що буде легко. Може здаватися: «це не моє», «це складно», «не цікаво», «я не можу, у мене лапки», але, погодься, програмування дає неймовірні можливості. І хай тобі в цьому щастить!