[Дмитро Волошин — співзасновник і CTO в Preply, організатор Kyiv CTO Meetups.]

Дисклеймер: усе нижчеописане — мій власний досвід. Обов’язково звертайтеся до лікаря, якщо у вас з’явилися найменші симптоми.

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

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

У рамках регулярного чекапу перевірився на IgG-антитіла (~5.96 при позитивності >=1.4, false positive rate ~2%). Я належу до категорії «людей, що перехворіли», але вже не в активній фазі:

Простими словами, є три типи антитіл: IgM, IgA, IgG. Якщо IgM позитивний, то людина «в середині/кінці» хвороби, якщо IgG  —  то людина вже перехворіла (довгострокові антитіла). Я робив тести на антитіла двічі . Перший  5 жовтня: IgM=0.5, IgG=0, а другий 23 жовтня: IgM=0, IgG=5.96. Узагалі здавати тести на антитіла напрочуд легко і швидко, це можна зробити у будь-якій мережевій лабораторії за 5 хвилин і ~500 гривень.

ПЛР-тестування під час самої хвороби не проходив, тому що в тестах тоді зашкалював відсоток false negatives і я не бачив змісту в цьому з огляду на симптоми.

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

Перебіг хвороби

Протягом карантину я старався дотримуватися соціальної дистанції і носив маску в закритих приміщеннях. Проте 26 вересня  у мене почала боліти голова і з’явилася легка температура. 27 вересня додався біль у горлі. з 27 вересня по 1 жовтня кожного дня була легка температура близько 37 градусів, апатія, втома. Горло і голова майже не боліли після першого дня. На четвертий день неповністю зникли смак і нюх, на восьмий день відновилися. З 1 по 10 жовтня  —  лише втома та апатія, низький рівень енергії. У моєму випадку це можна було б сплутати із застудою, жодних сильних симптомів не спостерігалось, як і кашлю. Також я вів щоденник симптомів, але він був майже порожній. З 27 вересня до 12 жовтня  я самоізолювався вдома.

Як я лікувався

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

Полоскання горла сольовим розчином кілька разів на день. Варто зазначити, що немає дослідження, яке доводить ефективність цього проти COVID-19, але на початку я не був впевнений, що це коронавірусна інфекція. Крім того, я розумів ефект від полоскання горла з цього дослідження:«As the cost of throat gargling with tap water or saline is inexpensive and almost free, the social and economic benefits of reducing UTRI might be huge [...] Throat gargling could reduce the viral load in the throat of patients with URTI. Although it cannot eradicate the virus, it can reduce the viral load in the oropharynx».

Супербагато гарячого питтядля уникнення дегідрації. Якщо є температура, людина потіє і втрачає багато води. Це варто компенсувати великою кількістю пиття. Те, що пиття гарячої води/чаю підвищує температуру всередині тіла, яка вбиває вірус, — міф.

Вітамін D. Сам собою він не лікує, проте приблизно у середині вересня я помітив, що у мене знижений рівень цього вітаміну (завдяки регулярним чекапам у «Синево») і почав вживати D3. У великої кількості людей, особливо у сфері ІТ, рівень вітаміну D понижений. Зверніть увагу: є кореляціяміж його рівнем і COVID.

Вітамін С.Немає доказів, що він допомагає при застудах чи COVID, але я старався вживати більше цитрусових, тому що цього хотів мій організм. До речі, нині популярним є відеолікаря Paul Marik, автора методу лікування через великі дози вітаміну C (Marik Protocol), і в січні 2020-гобуло завершено дослідження, що показало відсутність ефекту. Рекомендую його почитати, там досить цікаве протистояння науковців, які сперечаються про дизайн дослідження.

Регулярні заміри температури. Мені в цьому допомогло кільце Oura, яке постійно показувало температуру, навіть під час сну. Вона коливалась між 36.6 і 37.3.

Вимірювання рівня кисню в крові. Оксиметри коштують від 500 до 1000 гривень, і це хороша покупка. Коли я заміряю свій рівень кисню в крові й він становить 99%, то якось спокійніше стає.

Вихід з дому тільки в масці, їжа через доставку Glovo Prime з електронними чайовими (Smartass, Eat Easy, «Китайка» — це мій топ). Почав також їсти солодке, тому що цього хотів організм, хоча до того старався не вживати цукор.

Fun facts

Цікаво, що я вирішив перевіряти свої когнітивні здібності та здатність думати швидкими партіями в шахи (бліци на дві хвилини), з яких у мене стабільний ELO-рейтинг. На графіку видно просідання показників з 26 вересня до 10 жовтня. Зазначу, що 10–30партій щодня — репрезентативна вибірка. Відповідно, хороша проксі-метрика для відстежування свого стану, рекомендую.

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

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

Я добре розумію, як працюють A/B-тести і їхні «сестри» Randomized Double-Blind Studies. Те, що зараз відбувається з тестуванням ліків і вакцин — напівнаукові речі, можливо, людству варто вживати це як екстрений захід в часи пандемії. Вибірки маленькі, p-value смішні, метрики досліджень змінюються після одержання результатів. Хороший приклад — історія з ремдисевіром, коли автори змінили ціль дослідження після того, як одержали результати, що не підтвердили їхню початкову гіпотезу:

Інший приклад — нещодавнє дослідження, яке показало, що з 927 досліджень, пов’язаних з COVID-19, 52% виключили з вибірки вагітних жінок, 46% не згадали про вагітність. Лише в 1,7% досліджень враховували вагітних жінок, з яких лише три дослідження були інтервенційними. В науковому підході до тестування є поняття generalizability, також відомий як external validity. На жаль, ця практика типова в часи пандемії, проте чи зможемо ми довіряти результатам, які не тестувалися на певній підвибірці? Риторичне питання.

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

Висновки

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

1. Поширення вірусу.  Щоб його мінімізувати, варто носити маску і дотримуватись соціальної дистанції.
2. Ожиріння і серцево-судинні захворювання —  правильно харчуватися і спорт.
3. Вітамін D. Проводити заміри через загальний аналіз крові.
4. Сила імунітету. Здоровий сон, відсутність хронічних захворювань, різноманітні практики. Я, наприклад, практикую контрастний душ.

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

Не хворійте!

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

Читайте також: Ноутбуки замість ПК, безкоштовні ПЛР-тести та знезараження офісів сухим туманом. Як ІТ-компанії змінили умови роботи під час карантинута Как я переболела COVID-19. История дизайнера из Харькова.

[Роман Катеринчик, основатель IT-компании Artjoker, а также финтех продуктов MyCredit и OnCredit. Ведет свой ТГ-канал, в котором регулярно делится инсайтами и кейсами из будней IT-предпринимателя]

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

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

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

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

Правило 1. Составьте «Портрет сотрудника» и набирайте людей согласно ему

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

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

Мы провели мозговой штурм с «хранителями ценностей» в компании (то есть с тем составом, в софт-скиллах которого мы были уверены на 120%). Набросали список из 20 характеристик, и в итоге сократили до восьми. Никаких секретов, список в открытом доступе:

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

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

Если бы во время собеседования я мог бы задать всего один вопрос, я бы спросил: «Почему вы ушли из предыдущих двух компаний?». Расспросите от этом подробнее — про атмосферу, отношения с руководителем, командой, что заставило уйти. Этому вопросу я научился у Джека Уэлча (ex-CEO General Electric). «Причина, по которой человек ушел с работы, говорит о нем больше любой другой информации«,— пишет Джек. И практика показывает, что так оно и есть.

Правило 2. Системно избавляйтесь от всех слабых звеньев

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

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

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

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

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

Правило 3. Никогда не нанимайте сотрудника наспех

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

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

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

Что мы сделали? Снова наступили на грабли «взять впопыхах».

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

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

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

Правило 4. Соблюдайте принцип 14 дней на испытательном сроке

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

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

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

Традиционные два месяца испытательного срока можно смело сокращать до двух недель. В 90% случаев это окажется верным решением. Берите на вооружение лайфхак и не тратьте времени на людей, с которыми вам не по пути (а им — с вами).

Правило 5. У сотрудника должен быть один начальник

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

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

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

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

Вывод:если вы не хотите запутать своих сотрудников и создать нездоровую конкуренцию между двумя руководителями — придерживайтесь принципа единоначалия.

Правило 6. Общайтесь один на один с вашей командой

От вас когда-нибудь уходили ценные сотрудники? Любимчики или просто перспективные?

От меня да — и это очень неприятно. Хорошего сотрудника сложно найти, долго адаптировать, обучать и очень неприятно потерять. Особенно, когда тебе кажется, что все ок... А он приходит и говорит: «Я принял решение уйти!»

Руководитель — как хороший тренер: должен всегда чувствовать, в каком эмоциональном состоянии находится спортсмен, какой у него уровень подготовки и мотивации. И я сейчас не имею в виду материальную мотивацию или деньги.

Итак, мой топ-10 полезных вопросов для проведения 1-to-1 беседы с сотрудником:

• Каковы текущие блокеры для реализации целей и как я могу помочь тебе?
• За счет чего ты теряешь много времени в течение недели?
• Что нового ты узнал(а) на работе за последнее время? О чем хочешь узнать больше?
• Какими проектами за последнее время ты больше всего гордишься?
• Если бы ты мог(ла) что-то изменить в своей работе сегодня, что бы это было?
• Чувствуешь ли ты адекватную поддержку со стороны коллег? Почему?
• Есть ли какие-нибудь проекты, над которыми ты бы хотел(а) поработать, если бы тебе дали такую возможность?
• Что тебе сейчас нравится и вдохновляет в работе?
• Какие два-три новых навыка ты хочешь в обозримом будущем освоить на работе?
• Какие две-три вещи мы могли бы сделать, чтобы улучшить твою эффективность?
• Что можно улучшить в бизнес-процессах компании, чтобы сделать твою работу эффективнее?
• Есть ли у тебя какой-нибудь фидбэк для меня?

По статистике, если от вас уходит специалист, то ущерб для бизнеса составляет минимум шесть-восемь его зарплат! Расчет простой: сначала подбор займет время, а в лучшем случае, если второй человек подойдет, понадобится адаптация и обучение.

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

Правило 7. Сотрудники уходят от руководителя, а не от HR

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

Развею ваше заблуждение: работа руководителя — в том числе быть Лидером своей команды. А это значит:

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

Если у тебя в компании демотивированнная команда, которая не верит в лидера — никакой HR не поможет. Ни самый опытный, ни самый красивый, ни дорогой. Лидер должен решать вопросы мотивации своей команды самостоятельно!

Мы в Artjoker настолько заморочились с донесением культа Лидерства до руководителей отделов и тим-лидов, что даже вынесли семь ключевых правил лидерства, зафиксировав это в Книге жизникомпании:

1. Непрерывно развивай себя и свою команду.
2. Отождествляй свой путь с путем Artjoker.
3. Выстраивай искренние взаимоотношения.
4. Действуй и не бойся ошибиться.
5. Будь агентом изменений.
6. Будь примером для команды.
7. Бери персональную ответственность за результат.

Скриншот из Книги жизни Artjoker

Правило 8. Повышайте зарплату вместе с зонами ответственности

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

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

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

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

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

Держите формулу работы с пересмотрами, которые будут выгодны как сотруднику, так и бизнесу:

Добавляй ответственность — Повышай ЗП — Делай ревью результатов каждый месяц — Давай фидбэк сотруднику минимум раз в месяц — И так по кругу

Правило 9. Отмечайте достижения сотрудника

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

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

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

А для того чтобы сотрудники за свои победы получали системные «поглаживания» от компании, мы ввели ежемесячные звания «Best of the Best» (один человек из всей компании, который показал сверхрезультат), «Гордость месяца» (в рамках каждого отдела руководители выбирают, кого хвалить за достижения), «Взрывной новичок» (здесь мы хвалим новеньких за их драйвовое развитие).

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

Счастливая PM Аня, которая получила ежемесячную награду Best of the Best

Правило 10. Инвестируйте в обучение своей команды

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

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

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

На фото финалистки геймификации 2020-го«Книжный тетрис»

Вместо вывода

HR — это функция, а не волшебная таблетка!

С момента основания Artjoker и вплоть до 2016 года (10 лет!) мы жили без HR-менеджера. За это время мы выстроили корпоративную культуру и HR-бренд, сформировали сильную и вовлеченную команду, заморочились с «портретом сотрудника», обучали и развивали ребят, в том числе с помощью геймификации.

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

Мы наняли первого HR-менеджера (с прицелом на рекрутинг) только в тот момент, когда нам нужно было вырасти за год на +50 сотрудников. То есть у нового человека была четкая зона ответственности — расширить воронку входящих кандидатов, нанимать больше, качественнее и быстрее, чем мы это делали без него.

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

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

[Богдан Харчиков — специалист с 12-летнимопытом работы на различных должностях — программист, аналитик, руководитель отдела. Сторонник подходов постоянного улучшения (Continuous Improvement) и бережливого стартапа (Lean Startup). В поиске работы, которая станет призванием.]

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

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

Немного о себе. В IT с 3-гокурса ХНУРЭ. Работал программистом, аналитиком (BA, PO), проектным менеджером, руководил разработкой продукта американского стартапа, ставшего трудами многих талантливых людей успешной компанией.

Добился определенного количественного роста зарплаты, можете почитать «Как Junior Java Developer за 11 лет стал PM c $8000», и в какой-то момент осознал, что не в деньгах счастье, а в их количестве :) Шутка. Осознал, что не только в деньгах счастье. Хотелось ощущать себя частью чего-то большего — хотелось больше «силы сцепления» (англ. cohesion) с компанией и продуктом — и параллельно возникла боязнь засидеться на одном месте, где тебе платят больше за то, что ты делаешь именно для них.

Хочу рассказать в этой статье настолько подробно, насколько позволит договор о неразглашении и мой внутренний этический барометр, о следующем:

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

Интересно? Мне было тоже интересно разобраться, как такие компании в принципе существуют и работают.

Иллюстрация Марии Рыбак

Работа мечты

«Чтобы избежать разочарования,
надо уменьшить ожидания».
Неизвестный автор

Аккурат перед началом пандемии, в ноябре 2019 года, я уволился со своей работы, чтобы сделать небольшой, как я думал, перерыв, переосмыслить жизненные приоритеты, пройти наконец те 15 онлайн-курсов и прочитать те 25 книг, на которые никогда не хватало времени (и узнать, что, пока я строил карьеру, JavaScript стал наконец полноценным языком программирования).

Мой саббатикал затянулся. В разгар пандемии, в марте и апреле 2020 года, я еще пытался высылать резюме и собеседоваться в различные американские компании. Проработав последние пять лет полностью удаленно, я с удивлением понял, что ремоут не стал стандартом в отрасли, даже несмотря на локдаун, в большинстве вакансий указывалось: «Удаленно на время локдауна, потом в офисе» (в Харькове, Киеве, Нью-Джерси, Сан-Франциско).

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

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

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

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

Мое внимание привлекла одна вакансия на «Джинне», я сам написал рекрутеру. И за следующие восемь недель прошел все круги собеседования (HR — аналитик — архитектор — CTO — CEO), мне выслали офер, я приступил к работе, уже через две недели мне предложили повышение, а еще через 10 дней я уволился.

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

Этап первый — подготовка к собеседованиям

«Главный враг знания — не невежество, а иллюзия знания».
Стивен Хокинг

Итак, в описании вакансии значилось:

• ищем начальника отдела в удаленную команду;
• физического офиса нет и не планируется;
• аджайльный практик;
• работа со сложными техническими решениями уровня enterprise;
• 8-10лет опыта работы.

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

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

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

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

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

Идем дальше, на сайте компании значилось, что она сертифицирована по стандартам HIPAA, FedRAMP, SOC 2. Стандарты — отличный знак того, что компания достигла определенного уровня зрелости, имеет налаженные процессы, системы обеспечения безопасности и качества.

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

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

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

Этап второй — собеседования

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

Итак, вооружившись этими неправильными допущениями, я решил написать рекрутеру. Были озвучены следующие условия:

• График работы: мое раннее утро, позже большой перерыв днем и несколько часов вечером. «Иногда вечерние митинги», — говорили они. В итоге вечерние митинги были каждый день по два-три часа.
• Клиент ищет целенаправленно (в полностью распределенную команду?) только людей из Украины. Такой у клиента пунктик.
• Зарплата — средняя по рынку, но есть возможность поработать с теми самыми Google/Apple.

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

Сейчас я понимаю, что достаточно было попросить показать их burndown chart или бэклог, чтобы увидеть: скрам-атрибутами в компании прикрывался хаотический процесс уровня стартапа в первый год его жизни. А если дейли-митинг длится 45-60минут каждый день, нужно срочно вызывать скрам-полицию и арестовывать скрам-мастера :)

Типичная ошибка № 2 — вопрос «У вас же есть документация?» и типичный ответ: «Да, конечно, не идеальная, но она есть», и мой ответ: «Как я вас понимаю, идеально не бывает, но нужно к этому хотя бы стремиться». Не нужно на этом было заканчивать расспрос! Достаточно было открыть страницу со списком недавних изменений в Confluence, чтобы увидеть 5-сантиметровыйслой пыли на тех немногих документах, которые там присутствовали.

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

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

Этап третий — работа

«Если можете притворяться искренним,
сможете притворяться практически кем угодно».
Доктор Хаус

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

Вывод шестой: если перерыв на обед по плану пять часов, то постепенно это будет сокращаться до обычного одного-двухчасового. В итоге будете работать минимум по 10-12часов в день.

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

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

Этап четвертый — повышение и увольнение

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

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

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

Финал

«Этот Василий мне не подходит — несите следующего».
Владимир Кожаев, автор на ДОУ

Мне было сложно писать эту статью, переписывал ее несколько раз. С одной стороны, хотелось, чтобы все мои выводы звучали убедительнее, с другой — для этого нужно было бы показать все «грязное белье», которого было так много, что у меня в какой-то момент работы наступил stack overflow.

Несмотря на конечный результат (увольнение и неполная месячная зарплата), я рассматриваю этот период как очень крутой тренинг личностного роста (не путать с фильмом «Тренинг личностного роста»), за который мне еще и немного денег заплатили :)

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

Желаю каждому оставаться верным своим ценностям и идеалам и never settle for less.

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

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

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

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

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

Определимся с целями, или Как понять, что это твоё?

«Кожному своє — так було написано на воротах Бухенвальда»
Митець

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

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

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

Чего мы хотим?

«Бойтесь своих желаний — они имеют свойство сбываться»
«Мастер и Маргарита»

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

Потом начинается самое интересное. Задаем себе вопрос: зачем мне все эти пункты? Допустим, прибавка к зарплате. Что я куплю на нее, ничего? Тогда зачем мне прибавка? Новые технологии. Зачем? Ну я понимаю, нужно держать знания в актуальном состоянии, но будет ли эта технология популярна на рынке труда через пару лет? Удаленная работа тоже не для всех. Да, некоторые не могут работать дома и карантин это наглядно показал.

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

Если хочу интересной работы, что это такое? Может быть, интересует какой-то домен, или математика, или ещё что.

Совместимы ли требования, или Скучная прагматика о бизнесе

«Принцессы не какают бабочками».
Пособие для странствующих принцев

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

• полностью удаленной;
• свободный график: человек хочет путешествовать по разным городам;
• много платят;
• интересы сотрудников, их профессиональное развитие и приятное времяпровождение руководством ставятся выше прибыли;
• и вообще, компания должна приносить пользу людям!
• это не должны быть банки, страховые компании, гемблинг;
• очень желательно разрабатывать какой-то всемирно известный продукт типа GitLab;
• и самое интересное, человек — менеджер.

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

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

Любой бизнесставит во главу угла прибыль. Всегда-всегда-всегда-всегда. Кто делает по-другому, очень быстро обанкротится. Я прямо слышу, что кто-то, читая, заблеял козликом: «Бе-е-е, Илон Маск собирается строить город на Марсе, бе-е-е». Ага, собирается и тут же заявляет, что законы Земли на Марсе работать не будут. Вот вы представляете: колония на планете, в перспективе, возможно, целая планета и все там живущие имеют очень тесные связи с единственной фирмой. Это даже не деньги уже... «Звёздные войны» смотрели? Я приветствую тебя, Галактический Император.

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

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

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

И откуда вообще взялась дикая мысль, что нужный людям продукт и зарабатывание денег находятся в противофазе? В списке самых богатых людей мира Безос, Цукерберг, Пейдж. Компания Amazon или Google производит ненужные продукты, серьёзно?

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

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

Так что, записав требования на бумажке, подумайте: быть может, вы ищете несуществующий цветок папоротника?

Реальны ли наши хотелки?

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

Я это к чему: перед поиском работы хорошо бы посмотреть на рынок труда и определиться, не раскатал ли я губу очень сильно? Может, стоит попуститься слегка?

Где и что делать?

Теперь нужно определиться, где искать. Но существуют ли общие рекомендации (мы помним, что люди хотят разного)? Оказывается, существуют. Те, что я знаю, представлены ниже.

Большинство возможностей — в крупных городах

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

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

Некоторых работ в Украине нет!

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

Чтобы следующая работа была лучше предыдущей

Ведём себя правильно

Старый конунг, король викингов стоит на скале фьорда и говорит сам себе:
— Я, конунг Олаф, построил два прекрасных города. Но никто не называет меня «Олаф — Градостроитель!»
— Я, конунг Олаф, имею под своим начальством пять тысяч воинов! Но никто не называет меня «Олаф — военачальник!»
— Я, конунг Олаф, завоевал все земли от Британии до Греции, но никто не называет меня «Олаф — завоеватель!»
— Но стоило мне ОДИН РАЗ тр***ть овцу... (Из анекдота).

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

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

Третий подход состоит в выполнении неких неписаных правил. Хоть в контрактах это и не прописано, но большинство менеджеров крайне резко осудят уход разработчика за пару месяцев до релиза. Большинство... А опытные спросят: «Что же вы не предусмотрели релизных бонусов хотя бы для ключевых специалистов? Мало кто откажется доработать до конца проект, получив пару-тройку месячных зарплат».

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

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

Взвешиваем риски

Не меняем работу спонтанно и из-за незначительного преимущества. Решение должно быть прочувствовано и просчитано.К примеру, дают тебе на 300 долларов больше, вроде не так уж и мало, но станешь ли ты счастливым от этой суммы? С другой стороны, как там сложится на новой работе, еще не известно. Что, если придётся искать другую? Это потеря денег, переживания. Стоят ли они небольшой прибавки?

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

Ещё пример: получили вы хорошее предложение, но есть мелкие неудобства. Соглашаться или искать точно такое же, но с перламутровыми пуговицами? Можно ведь и не найти!

Поиск работы — это тоже работа

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

Взялся за гуж, не говори, что не дюж

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

Сводные характеристики компаний

На собеседованиях часто можно услышать: зарплата у нас средняя по рынку (это значит, что значительно ниже средней), зато коллектив хороший/работа интересная/etc. Не верьте — это наглая ложь и попытка манипуляции. Давайте подумаем, в каких конторах хорошо работается? Начнём издалека.

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

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

Почему? Конечно, люди хотели бы платить разработчикам как можно меньше, но они понимают: за мало толковых не найдёшь.

Даже если найдёшь, программировать на голодный желудок, когда думаешь, что твоим детям нечего есть, не на что купить им игрушку, не выйдет. Инженер должен быть отдохнувшим, счастливым и довольным жизнью — тогда он работает хорошо. Вы думаете, в Google программистам разве что сопельки не вытирают, потому что Брин, Пейдж и Шмидт добрые феи с волшебными палочками? Ага, сейчас!

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

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

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

Итак, характеристики компаний...

Хороших

Не бывают мелочно жадными

Пример: в одной николаевской ІТ-конторе в далёком 2006 году собирали по 5 гривен на установку ёлки. Ёлки, блин! Точно такой же, как я себе покупал в дом. Класс, да?! А ещё эта компания знаменита работой в две смены за одним компьютером. С 07:00 до 15:30 и с 16:00 до 24:00, полчаса на обед. А вишенка на торте — штрафы за опоздание. Ни снег, ни дождь, ни град, ни транспортный коллапс для отмены взыскания не причина. Охранник с секундомером на входе. С секундомером — не вру. Опоздал на пять минут — всё, половина рабочего дня в минус. Хорошо, что я подружился с тамошней охраной и они мне опозданий не отмечали.

Не корчат из себя Google

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

И плохих

Надменные

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

Невыполнение обязательств

Очевидно, что плохо, если не платят зарплату тебе. А если другим? Тебя ведь пока не трогают. Пока... но обязательно тронут, как только станет выгодно — сразу же. Вам не нужна последняя зарплата? Тогда идите работать в фирмы, которые не платят djinniза найм :)

Другой пример, сразу после кризиса 2008 года я собеседовался в ещё одну игровую контору, и ходили слухи, что там зарплату задерживают. Я спросил, мол, правда ли это? Эйчар отвечает:

• Да, было, но новым людям мы стараемся не задерживать.
• А старым?
• Бывает, но все, кому не нравится, уже уволились.

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

Рассказы о пассионарности

Хороший программист (звучит как настоящий мужчина, правда?) должен работать без технического задания и очень-очень любить свою работу. Если работа не сделана, чувство долга не даст ему уйти домой. А ещё, если компании надо, хороший программист продаст жену, дочку и почку.

Все эти рассказы о том, как нужно Родину любить, — очень плохой признак.Есть на украинском рынке такие менеджеры: дикая помесь советского директора колхоза, продажника МММ и капризной проститутки. Когда ему нужно, компания — твои лучшие друзья, семья, дом, да всё, что захочешь, только останься сегодня допоздна и закончи вот эту работу (но завтра нужно прийти обязательно вовремя). Однако, когда речь идет о том, чтобы тебя уволить, что ж — это бизнес.

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

Тимлид — задрот

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

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

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

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

Хотите такого руководителя, нет? Но как же его распознать.

• На собеседовании человек больше говорит сам, чем слушает, и в основном о технологиях.
• Речь скороговоркой.
• Оптимистические сроки.
• Неумение слушать собеседника.

Если видите такое, рекомендую вежливо выслушать и пойти дальше искать.

Куда податься, если...

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

Главное — деньги

За что их платят больше среднего. Вот список по убыванию приоритетов:

• Ответственность за других. Если чувствуешь в себе силы довести проект с начала и до конца, при этом в рамках временных ограничений и бюджета, тебе прямая дорога в менеджмент. Помните, я выше писал об обратившемся ко мне ищущем менеджере? Так вот, он зарабатывает, не скажу сколько, но сильно выше среднесибирских четырёх тысяч в месяц.
• Редкие, но востребованные рынком навыки. Предметные области с высоким порогом входа.Ходят слухи, что за COBOL, например, можно получить очень много — людей нет. Но и проектов таких тоже немного. Еще можно пойти в анализ данных. Учиться тяжело, долго, зато зарплаты хорошие.
• Умение решать cложные технические проблемы.На техлидов со знанием какой-нибудь Java или C# и видящих разработку в целом, можно сказать, охотятся ІТ-компании, предлагая вкусные условия. Для этого, правда, нужно не только учиться, но думать постоянно, что же за задачу ты решаешь.
• Работа в денежной отрасли. Как вы думаете, где больше платят при прочих равных: в обсерватории или банке? Ответ предоставляется читателям в качестве упражнения. Ещё тароват гемблинг, блокчейн. И в трейдинге, говорят, вкусно кормят.

Хочется стабильности

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

Казаку воля да добрый конь

Если хочется свободы, милости прошу во фриланс. Зарабатывать будете на первых порах немного, потом с обрастанием клиентурой не хуже, чем толковый тимлид в аутсорсинге. Почему? А найти клиента, чтобы платил вовремя и без кидалова, — это едва ли не самая сложная задача! Кстати, решая её, начинаешь понимать, что кровавый аутсорс — самый лучший друг программиста!

Не было бы его, работали бы вы, товарищи-снобы, админчиками в «Укртелекоме» (и то это кому как повезёт). Самые удачливые — в государственных банках с их обязательным приходом к 8 утра и отношением к айтишнику как к странному нищему мальчику в растянутом свитере. А самые-самые везучие попали бы в оборонку проектировать дроны, хоть квартиры дают (ну, или могут дать). Да-да, в ту самую оборонку, куда при наличии аутсорсинга ну никак не найти людей. Поиск клиентов — это занятие, сильно отличающееся от написания кода.

Интересная работа

Конечно, интересно всем разное, но сложная работа обычно в науке и рядом. Платят меньше, чем фрилансеру, но интересно. Настолько, что большинство работает за 1/10 от суммы, что можно получить в бизнесе, и по вечерам подрабатывает тем же фрилансом. Ещё учёному легче уехать за границу, правда, и там жировать он не будет. Мне как-то предлагали контракт в Сингапур, интересная задача и платят много по украинским меркам. Но налоги! Пришлось бы каждую копейку считать. А город очень дорогой, за скромное жилье пришлось бы отдать в лучшем случае половину зарплаты.

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

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

Чтобы не пропустить новые статьи Вовы Кожаева — подпишитесь на него в телеграм-боте Ленты DOU.

Мене звати Максим, мені 36, працюю Product Owner в компанії Customertimes. Народився, вчився і майже все життя прожив у Києві. Кілька років провів в Італії — у дитинстві, а згодом отримував там MBA у Bologna University Business School (банківська сфера та фінанси) та стажувався у головному офісі UniCredit, Мілан. Трохи побачив світ: відвідав 30+ країн. І от три з половиною роки — з червня 2015-годо жовтня 2018-го —прожив в Одесі. Цією історією хочу поділитися з вами.

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

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

Схід сонця в Одесі

Як я опинився в Одесі

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

У 2015 році одна з великих компаній активно сватала мене до Польщі, але у них все відбувалося ну дуже повільно — тижнями. Одного вечора — пам’ятаю, це був четвер, — побачив вакансію в Одесі та вирішив «суто заради приколу» надіслати CV. Уже наступного дня мені зателефонував рекрутер. У вихідні я виконував тестове завдання. У вівторок проходив онлайн-співбесіду з Delivery Manager. У четвер — із клієнтом. Як казав класик: «Шутки шутками, но могут быть и дети». Тож у понеділок у мене був офер і... шок. Я мав переїхати за 15 днів. А ще 10 днів тому це все було лише жартом. Ішлось про дуже цікавий проєкт: велика компанія, аутстаф, клієнт — компанія із Fortune 100, фінансовий домен, пряме підпорядкування Product Management на боці клієнта... Хто розуміє, той оцінить. Я «был вынужден согласиться».

Переїзд

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

Офіс був дуже комфортним, у частині політик, тренінгів мінімум бюрократії: одразу онбордишся на проєкт. Команда теж зробила все, щоб я почувався як удома. Мене зустрів Delivery Manager, приділяв мені достатньо уваги. Я багато чого навчився у нього з погляду дипломатії, гумору, IT-ринку. DevLead — хлопець у малиновій футболці та джинсових шортах — розповів про процеси та церемонії. Мені його дрескод після 10 років корпоративної культури був трохи незвичним.

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

Житло

До переїзду в Одесі я був лише кілька годин проїздом, а в усьому місті знав лише одну людину. Але саме вона й допомогла знайти квартиру, яка задовольнила мої вимоги. Одразу скажу: жив у самому центрі, на розі Гаванної та Ланжеронівської вулиць, де розташований ресторан смачної української кухні «Куманець». Офіс компанії був на Дерибасівській. Тож 90% часу я проводив у центрі, а у віддалені райони їздив рідко, скільки разів — можна «посчитать пальцами одной руки». В основному для шопінгу («City Center» на Таїрова та «Рів’єра» на Фонтанці), навідував друзів у Grande Pettine та «Совіньйоні». А також, на жаль, потрапив в обласну лікарню.

Функція пошуку оптимального житла має безліч параметрів, і всі вони персональні. Я вирішив жити поруч з офісом, у самому центрі. Мені по кайфу бути у вирі подій. І я не хотів витрачати по дві години на день просто на дорогу. Так, я більше платив за оренду. Але якщо врахувати витрати на транспорт, — наприклад, таксі ввечері, бо плентатись в маршрутці після важкого дня «это не фэн-шуй», — та й ті «загублені» дві години на день, то дешевше виходить жити в центрі. Крім того, усього за 20 хвилин можна дістатися до моря. Всі активності теж поблизу.

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

Перші враження та адаптація

Перші враження про місто були змішані. З одного боку, було складно через шалений темп на роботі: увімкнутися в процес потрібно було «ще вчора». Графік — зміщений: спілкувався з клієнтом в неробочий час (West Coast). Тому в деякі дні доводилось сидіти в офісі до 9-ївечора, а часом і довше. Але й починав працювати пізніше, близько 12:00.

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

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

А ще прогулянки... Я зносив багато пар взуття, гуляючи «Горсадом», сквериком Остапа Бендера, Дерибасівською, Пале-Рояль, Катерининською (вулицею і площею), Приморським бульваром, Тещиним мостом, Потьомкінськими сходами, Стамбульським і Грецьким парками, площею біля Оперного, біля будинку з однією стіною та у справжньому одеському дворику навпроти (там ворота зазвичай відчинені), а ще Морвокзалом і парком Шевченка. До речі, там на Алеї Слави вічний вогонь горить весь час. І це викликає велику повагу. Мені також дуже подобаються одеські вказівники з назвами вулиць. Вони розташовані на перехрестях у центрі та допомагають краще орієнтуватись містом. А ще вони дуже милі.

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

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

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

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

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

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

Згодом я вже не почувався самотнім, а на роботі стало легше. Вивільнилось більше часу та з’явилась компанія, щоб потусити. Не дуже люблю гламурні та помпезні місця: в «Ібіці», «Парку Резиденс» та «Ітаці» був лічені рази. Мені більше до смаку душевні клуби: True Man (сходи сонця там магічні) та «Пляжник». Кілька затишних закладів є і в центрі, наприклад Central Bar, The Fitz, Trevelers Coffee.

Побут

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

Треба бути готовим до того, що в супермаркеті в Одесі продукти теж дорожчі, ніж у Києві. Якщо порівнювати з цінами «Мегамаркету» на метро «Олімпійська» (а це недешевий магазин), то молочка, яйця та інші продукти в «Таврії» дорожчі приблизно на 10%. В «Обжорі» вони коштують ще більше: цей супермаркет цілодобовий.

Також в Одесі дорожчий інтернет. За місяць підключення через провайдер soborka.net платив близько 190 гривень. Для порівняння: у Києві на Печерську зараз плачу за батьків 90 гривень за bilink.ua і 155 гривень за kolo.tv. На момент від’їзду ці ціни в Києві були ще нижчі.

Транспорт

Додому їздив щомісяця, іноді кілька разів. Спочатку «Чорноморцем» (з Одеси вирушає о 22:30, у Києві вранці о 7:00), поки ціни були «людські»: близько 500 гривень за СВ, згодом квиток вже коштував приблизно 800. Потім пересів на Intercity. Для мене розклад був зручний: з Одеси вирушає о 5:30, а до Києва прибуває близько 13:00; з Києва — о 16:30, в Одесі — близько 23:30. Комфортно в цьому потягу почуваюся. Кілька разів літав Bravo Airways, але, на жаль, швидко рейс скасували й «дурничка закінчилась».

Також нормальна альтернатива Intercity — це автобуси: Gunsel та Autolux. Мені більше до вподоби перша компанія. Щодо цін — усе демократично, вартість квитка близько 400 гривень. Сервісом BlaBlaCar користувався двічі, мав не зовсім приємну історію. А після подій у Львовіприпинив.

Міським транспортом в Одесі їздив мало: здебільшого маршрутками. Трохи незвично платити при виході. Але проблеми у цьому зовсім не бачу, із часом звикаєш. Кілька разів катався на трамваї Французьким бульваром. Стан вагонів не дуже, але жити можна.

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

Таксі я користувався дуже часто, тому історій мільйон. Розкажу дві. Одна допоможе пройнятися атмосферою міста. Друга — стосується нас із вами. Мені пощастило кілька разів їздити з одеситом віком 60+ років. Він розказав багато цікавого про місто, і я йому за це безмежно вдячний.

Коли їхали біля одного будинку, він сказав: «Вот тут я жил много лет назад. А вот из этой парадной выбегал молодой Дима Харатьян с пистолетиком, когда снимали фильм „Зеленый фургон“. Вы смотрели? Нет? О-о-о...». І тут він на мене подивився типу: «А шо вы вообще знаете за жизнь, молодой человек...». Після цього порадив подивитися кілька фільмів, які знімала Одеська кіностудія (до речі, туди просто обов’язково раджу сходити на екскурсію). А саме: «Приморский бульвар», «Зеленый фургон», «Мы из джаза». Перегляньте, не пожалкуєте.

Інша історія сталася літнього ранку. Я поспішав на вокзал, і мене віз дядько 60 років. Я поцікавився, за скільки часу домчимо. На що він відказав: «Ну, если встречных камней не будет, то минут за 15 долетим». Їдемо й бачимо біля Оперного молоду парочку: цілуються і роблять селфі. А далі чую 5-хвилинниймонолог: «Вот что это такое? В нашем языке столько этих иностранных слов. Селфи... ну есть же нормальное слово „фотокарточка“. Или это... джем... отличное слово „варенье“. А вот это вообще меня убило... IT-специалист». До цього я мало не вибухав від сміху, але мужньо тримався. «В Советском Союзе не было никакого IT-специалиста. Вот мы говорили — „электронщик“, и всем все сразу было понятно». Ну тут я вже не витримав і просто розреготався.

Атмосфера міста

Одеса має свій ритм і мікроклімат. Тут майже все «на расслабоне», зайвий раз люди не хочуть «делать себе нервы». Багато чого відкривається об 11:00. Тоді як у Києві зазвичай все стартує о 9:00 або 10:00. Люди значно позитивніші, ніж у Києві. До переїзду я часто їздив у метро. Щоб уранці побачити усмішку, це має пощастити. В Одесі все інакше.

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

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

IT в Одесі

І нарешті тема, яка, мабуть, дуже цікавить колег, а саме — що ж в Одесі з IТ? Одразу скажу, що не проводив детальних досліджень щодо кількості компаній, їхньої специфіки роботи, вакансій тощо. Знаю, що на той момент у місті були присутні гравці як національного/міжнародного калібру — Ciklum, Luxoft, DataArt, BeetRoot, Oracle, так і локальні компанії: Provectus, Lohika, Comodo та інші. Проводились meet-ups з різних компетенцій IT, зокрема з DevOps, PM Day тощо.

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

Повернення до Києва

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

Розповідав новим колегам свою історію. Питають: «Как тебя угораздило из Киева уехать в Одессу?». Відповідаю: «Неправильный вопрос. Спросите лучше, как угораздило из Одессы вернуться в Киев?». Звичайно, це жарт, бо Київ — це мій дім. Але я жодного дня не розглядав свій переїзд як downshifting.

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

Висновки

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

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

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

Сподіваюсь, моя розповідь стане комусь у пригоді. Жити в Одесі — це випробування. Для мене воно виявилося класним. Бажаю, щоб для вас воно було ще кращим.

Щоби не пропустити нові статті Максима Мурзака — підписуйтеся на нього у телеграм-боті Стрічки DOU.

Привіт, мене звати Северин, більше шести років я працюю в ІТ та близько року в ролі Scrum Master — встиг набратися досвіду і як розробник, і як проєктний менеджер.

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

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

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

Види мітингів

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

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

Якщо ми говоримо про адаптивне (Agile) середовище, ці мітинги вже є не просто статус-мітингами. Правильніше їх назвати дейлі-синкапами. Тут уже не проєктний менеджер приймає роботу, а команда. Чому саме так? Тому що в Agile-середовищі позиція PM відсторонена від команди розробників/виконавців. Відповідальність за виконання зміщена від PM у бік команди та власника продукту. Саме команда найбільше зацікавлена в тому, щоб робота була зроблена вчасно та якісно. Тому синкап — це синхронізація насамперед колективу.

Розібралися. А тепер перейдімо до оновлень. Тут усе просто: це актуальна інформація щодо виконання завдань.

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

Що таке апдейт

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

• Що зробив учора?
• Що буду робити сьогодні?
• Чи є щось, що не дає мені досягти поставленої цілі?

Ці три питання є сакральними. Вони дають базу для роздумів: чи справді мені немає що сказати на дейлі-синкапі?

Йдемо далі. Що означає «немає апдейтів»? За останню добу чи від останнього мітингу нічого не відбулося на проєкті? Чи немає оновлень, бо не просунувся далі в роботі, або немає що показати, адже ще працюю над завданням? Ось у цьому велика різниця!

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

Задача ще не зроблена? Можливо, не просунувся в роботі, але старався і пробував варіанти? Це теж важливо. Наприклад:

1. Намагався вирішити, але не вдалося.
2. Не зробив, бо був заблокований чимось.
3. Нема апдейтів, бо ще в роботі.
4. Не готово через особисті причини тощо.

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

А тепер до кейсів

Розгляньмо вищезгадані приклади докладніше.

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

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

Не зробив, бо був заблокований чимось. Класичний випадок. Скільки разів ви були змушені чекати на те, щоб вас розблокували. Наприклад, на код-рев’ю, вхідні дані від клієнта або система не працювала тощо. Як правило, нас можуть блокати банально через те, що контрагент (людина, якій передане завдання) не до кінця розуміє пріоритет завдання або з тих чи інших причин забув його виконати. З ким не буває?

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

Ще один варіант ефективно використовувати час — мати запасні задачі, так звані Stretch Objectives. Тобто якщо ви заблокані або швидко закінчили першочергові таски, щоб не сидіти без діла, беріться до виконання запасних.

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

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

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

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

Шпаргалка для керівника-початківця

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

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

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

Висновок

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

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

Якщо вам цікаво спілкуватись або бажаєте бути в контакті, додавайтесь в LinkedInабо читайте мене на Medium.

Щоби не пропустити нові статті Северина Рибчинського — підписуйтеся на нього у телеграм-боті Стрічки DOU.

Усім привіт! Мене звати Олексій Остапов, я понад 12 років працюю в IT, у компанії Infopulse, займаюся тестуванням, автоматизацією, тестую викладання в КПІ, веду про тестування блог... і часто повторюю слово «тестування».

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

Чому взявся за цю статтю

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

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

Менеджмент — цікаво і корисно, але не для всіх. Бо не всі тестери — менеджери. І не всі навіть хочуть ними стати. Я от спочатку хотів. Потім не хотів. Зараз я лід. П — послідовність.

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

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

Чому факапи

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

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

Халк ламати

Почнемо з нашої професії. Коли я почав працювати, мені дали ПЗ і сказали: «Давай! Забабахай exploratory testing». І я почав тестити. Усе, що можна і не можна. Є навіть гарний спогад: показував баг нашому деву і питав: «Так має бути чи це фіча?». Він кілька хвилин сумно дивився в монітор, а потім видавив: «Ну, заводь... я б ніколи не подумав, що таке можливо...». Я ніби фізично зробив йому боляче.

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

Мітинги

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

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

Чи от така ситуація. Вас кличуть на «лівий» двогодинний мітинг, де вже 20+ людей. І ви йдете, бо там менеджмент і взагалі складно відмовити. І потім дві години читаєте новини на м’юті, бо вам нецікаво і від вас теж нікому нічого не треба. У якийсь момент я став виходити з таких мітингів, якщо розумів, що тут я не потрібен.

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

Дух дослідництва

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

Це підводить до наступної історії: мене серед іншого дуже цікавить тестування навантаження. Я дослідив кілька тулів, написав кілька статей і постів у блог, виступив торік на конференції та отримав й критичні коментарі — і сетап не такий, і тести не такі, і тести зробив на Windows, а не на Linux. Єретик! Ніхто так не робить!

Так от, що я маю вам сказати: всі знають, що Linux рулить, а Windows must die, але майже ніхто не може пояснити чому. Наскільки і в яких задачах Windows гірше працює?

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

Тож не бійтеся братися за те, що збоку здається дивним. Головне — робити висновки потім. Моя думка така: нам як спеціалістам має бути цікаво знати, що можуть наші тули, в яких умовах і на якому «залізі».

Конференції, викладання, блог

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

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

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

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

Висновки

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

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

А тепер розкажіть про ваші улюблені фейли в коментарях!

Стаття написана за матеріалами доповіді на QA Day 2020. Ілюстрації — авторські.

Щоби не пропустити нові статті Олексія Остапова — підписуйтеся на нього у телеграм-боті Стрічки DOU.

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

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

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

Я Кристина Голышева, создательница дизайн-рекрутингового агентства Hirey.io. Сегодняшняя статья о Diversity, Equity & Inclusion. DEI — это понимание того, что каждый человек уникален, признание наших индивидуальных различий. Этими различиями могут быть раса, этническая принадлежность, пол, сексуальная ориентация, социально-экономический статус, возраст, физические особенности, религиозные или политические убеждения и прочее.

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

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

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

Intro

Источник

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

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

Причина, по которой вы не смогли сразу отгадать загадку, — неосознанные предубеждения. Они тысячами лет помогали людям выживать. Мы должны были понять, кто представитель нашей стаи, а кто — чужак. Кто друг, а кого стоит остерегаться. Времена меняются, и сейчас эти предвзятости больше не нужны. Но они настолько прижились в нашем бессознательном, что мыслить объективно можем, только если подловим себя на bias’е, проанализируем его, «переступим» через него, тогда уже сможем судить объективно о ситуации.

Это хорошее упражнение, но оно станет лишь точечным решением проблемы bias’а в одной из миллионов подобных ситуаций. Чтобы бороться с этим глобально, важно осознать, что Diversity, Equity & Inclusion — это long run, целый концепт и методология. Это система, которую нужно намеренно внедрять в культуру компании. Чтобы DEI-стратегии сработали, они должны быть вшиты в нее.

Почему это важно

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

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

MacKinsey в своем исследованиидоказали, что компании, которые находятся в верхнем квартиле по расовому, гендерному и этническому разнообразию, получают на 35% больше прибыли, чем компании с меньшим уровнем diversity. Диаграммы иллюстрируют вероятность финансовых показателей выше среднего по рынку у тех, кто заботится о расовом, этническом и гендерном разнообразии:

Источник

Дин Стокер, CEO компании Alteryx, в своей статье для Forbesобъясняет одну из причин успешности инклюзивных компаний: «В моей компании пользователи — в 80 странах. Они говорят на многих языках. Это мужчины, женщины, ЛГБТК и представители практически всех национальностей. Поддержка наших пользователей и создание для них качественных продуктов требует разнообразия в том, как мы создаем эти продукты, а это означает, что в наших командах будет задействован полный спектр людей, в том числе в высшем руководстве и совете директоров».

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

Что такое Diversity, Equity & Inclusion

Diversity

Наиболее близкий перевод — разнообразие. Отвечает на вопрос Who is at the table?Дословно: кто за столом, а значит, кто участвует в принятии решения, кто в команде?

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

Словом diverse мы можем охарактеризовать команду или организацию. Но понятия diverse candidate не существует, так как, называя одного из участников «diverse» (например, женщины в команде Data Science), мы автоматически присваиваем остальным (гетеросексуальным мужчинам) категорию «нормальности». Diversity — это относительное понятие. Оно проявляется в составе команд и измеряется в зависимости от ее участников.

Мы все разные, и наша работа в качестве хайринг-менеджеров или рекрутеров заключается в создании команд, которые признают, развивают и ценят разнообразие в своих коллективах. Например, в Google несмотря на то, что каждый из рекрутеров должен использовать стратегии поиска diversity talent, есть еще и целая команда Diversity Recruiters, которая постоянно занимается underrepresented groups in tech (недопредставленными группами в IT). Они фокусируются на работе с женщинами-разработчиками, lgbtk+, black, latin+ и другими кандидатами.

Для вдохновения предлагаю посмотреть невероятно крутое видео от Appleо Diversity & Inclusion.

Equity

В переводе — справедливость, беспристрастность, равенство. Отвечает на вопрос What are the barriers in getting to and staying at the table?То есть какие существуют барьеры к тому, чтобы оказаться и удержаться за столом?

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

Вот крутейшее визуальное объяснение еquality (равенство в условиях) и еquity (справедливое равенство):

Источник

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

Например, в Google те, кому нужно отвести деток в школу, а потом забрать их, могут начинать работать раньше, но и уходить в 15:30–16:00,что совершенно не влияет на закрытие метрик и не вызывает вопросов у руководителя.

В своей статьео DEI CEO компании Feminuity Sarah Saska сравнивает equity с тем, как компания выдает своим сотрудникам брендированные футболки:

• если бы компания выдавала всем универсальный размер, например L, многим футболка бы не была удобной, а некоторым бы и вовсе не подошла;
• если бы компания выдавала их в зависимости от размера — XS, S, М, L, XL, было бы гораздо лучше;
• но что, если бы компания давала футболки нужного размера только тем, кто действительно хочет их получить? Если бы у тех, кто не хочет футболку, была возможность взамен заказать другой мерч?

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

Inclusion

В переводе — включение. Отвечает на вопрос Do all feel they belong at the table?Чувствуют ли все, что они включены в развитие продукта, принятие решений?

Инклюзивность не появляется естественно, даже если все наши команды diverse. Руководители и сами сотрудники должны создавать ее. Инклюзивный дизайн — это дизайн для всех. Это об опыте кандидата или сотрудника в компании: насколько ему комфортно, исходя из личных/культурных потребностей? Чувствует ли он, что будет услышан?

Главным в инклюзивном дизайне организаций, процессов или продуктов становится принцип Ban the аverage. Примером такого дизайна являются звуковые сигналы для людей с нарушением зрения на светофорах в Украине или наличие комнат для медитации либо молитв во многих крупных компаниях в США, чтобы те, кто, согласно верованиям, молится несколько раз в течение дня, могли уделить этому время.

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

Что делают FAANG и другие техгиганты

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

• Managing Bias at Facebook;
• Unbiasing with Google.

Затем многие начали создавать Diversity Reports, в которых рассказывают о своем прогрессе в diversity-найме и удержании. Также они публикуют информацию об этническом, расовом, гендерном соотношении в своих командах:

• Diversity at Google;
• Diversity at GitHub;
• Diversity at Dropbox;
• Diversity at Apple;
• Diversity at Ford Foundation.

Они развивают kickstart-программы для тех, у кого, возможно, не было доступа к качественному техническому образованию:

• HBCU (Historically Black Colleges & Universities) program от Google;
• TechPrepот Facebook;
• Women Techmakersот Google.

Были созданы организации, цель которых — развитие DEI в IT:

• Catalyst — помогают делать компании более women-friendly;
• WIT (Women in Technology);
• Black Girls Code;
• Include — помогают имплементировать DEI.

Выводы

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

P.S. Язык во многих лингвистических школах — отображение национальной культуры, мира, обычаев, ценностей социума. Язык и культура — полностью взаимосвязаны. Отсутствие некоторых слов или терминов в нем, невозможность описать какой-либо концепт в большинстве случаев говорит об отсутствии этого концепта в культуре. Это я к чему? Кажется, нам стоит придумать слова для обозначения важных англоязычных терминов, о которых сегодня говорили в статье :)

Чтобы не пропустить новые статьи Кристины Голышевой — подпишитесь на нее в телеграм-боте Ленты DOU.

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

Мене звати Юлія Шишенко, багато з вас уже знають мене як кар’єрну консультантку та IT-рекрутерку. Кілька місяців тому за допомогою моєї статтітисячі професіоналів уже створили чи скоригували ідеальний профіль у LinkedIn. А сьогодні я не тільки допоможу скласти своє перше резюме легко та швидко, а й розповім, чому воно потрібне насамперед самому кандидату, щоб якісно та свідомо будувати кар’єру.

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

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

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

Принципи резюме

Резюме — це організаційний документ, який допомагає роботодавцям:

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

Навіщо резюме самому кандидату:

1. Щоб нічого не забути. Ви не уявляєте, скільки годин я проводжу з кандидатами на консультаціях, щоб вони згадали хоча б якісь свої досягнення на роботі. «У мене немає досягнень» — ось найпопулярніша фраза кандидата. Та ні, вони є, але людина їх просто не пам’ятає. Часто буває, що професіонал роками працює для бізнесу роботодавця, але потім навіть не має що в резюме написати. Для будь-якого професіонала резюме — це робочий файл, з яким варто постійно працювати.
2. Щоб розуміти, що кар’єра розвивається правильним шляхом. Більшість професіоналів відкриває своє резюме тільки тоді, коли шукає роботу. А кар’єру оцінюють або сумою зарплати, що непоганий показник, але він не завжди спрацьовує, або орієнтуються на записи в трудовій книзі, що сумнівно, особливо для ФОПів :) Або ця кар’єра живе десь в уяві професіонала. Я ж пропоную вам обрати більш аналітичний шлях, коли потрібна інформація міститься в єдиному документі, у зручному письмовому вигляді.
3. Щоб обирати майбутнього роботодавця та компанію, яка відповідає вашому рівню.
4. Щоб розуміти, де і чого вчитися. У мене часто питають, чи йти здобувати MBA, чи проходити якесь інше дороговартісне навчання. Який напрям обрати, якщо людина переходить з іншої сфери в IT. Чи на який IT-курс піти вчитися. Я завжди пропоную звернутися до свого власного резюме. Там є вся історія, там можна спрогнозувати, чи буде це навчання корисним і потрібним професіоналу.
5. Щоб мати гарну мотивацію та самооцінку. Сьогодні ми попрацюємо з тим, щоб ви самі собі заздрили, який ви класний спеціаліст.
6. Щоб професіонал міг у будь-який час знайти для себе роботу. Тому тримайте резюме в актуальному стані. Для цього відкривайте його хоча б раз на місяць і працюйте з інформацією.

У резюме є два типи інформації:

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

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

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

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

Мова резюме

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

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

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

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

Назва файлу

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

Сам файл з резюме можемо підписати так:

Якщо резюме англійською:

CV_Junior Python Developer_Ivan Tymko_Nov2020_Eng

Якщо резюме українською:

CV_IT Project Manager_Катерина Михайленко_Лист2020_Укр

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

Така форма підпису виконує всі необхідні функції:

1. Визначає тип документа. Що це саме резюме, а не якийсь інший документ. Ваш майбутній роботодавець може працювати із сотнями різних матеріалів.
2. Містить назву посади, на яку кандидат подається. Один рекрутер може вести одночасно 10–30 вакансій.Резюме інколи зберігають безпосередньо в HR-систему з пошти рекрутера чи із сайту, через який кандидат подав відгук. Уявіть, який є ризик, що документ збережуть у неправильному розділі, навіть якщо це робить автоматизована система, а не людина. Плюс, якщо вакансія закрита, а потім буде ще один набір, то файл з такою назвою буде легше знайти.
3. Містить повне ім’я кандидата. Зверніть увагу, що ім’я скрізь пишемо згідно з міжнародним стандартом: спочатку ім’я, а потім прізвище.
4. Є дата актуальності резюме. І самому кандидату важливо знати, коли він востаннє його обновляв.

Дизайн резюме

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

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

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

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

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

Психологія опрацювання резюме є трохи іншою. Якщо у роботодавця є 100 резюме кандидатів і тільки одне вакантне місце, то він повинен якимось чином обрати цього єдиного кандидата. І обирати його він буде саме через деталі. Важливо у резюме не писати величезними червоними буквами, наприклад, організаційну фразу «ДОСВІД РОБОТИ», бо вона жодним чином не відрізняє кандидата від інших кандидатів-конкурентів. Роботодавець буде шукати саме ті деталі, які відрізняють кандидатів одне від одного, а не загальні фрази.

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

Що не варто додавати в резюме:

1. Таблиці, бо самому кандидату повинно бути зручно працювати з цим документом, а не виправляти щоразу таблиці, які будуть з’їжджати у різні сторони.
2. Горизонтальні чи вертикальні лінії. Вони роз’єднують блоки надто сильно. Візьміть книгу чи статтю. Зазвичай там розділи не розмежовують лініями. У невеликому резюме достатньо зробити відступ і простір в один чи два рядки, щоб роботодавцю було зрозуміло, що вже починається інший розділ. Нормальна структура не вимагає жодних ліній.
3. Логотипи колишніх роботодавців чи навчальних закладів. У резюме ми не рекламуємо нічого, крім власного професіоналізму. Та й у такій інформації немає сенсу. Достатньо назви компанії словами.
4. Знаків, які означають імейл, телефон, месенджери тощо. Увагу забирають, а значення не мають.
5. Назви технічних блоків: Контакти, Досвід роботи тощо. Зазвичай всім і так зрозуміло, де у резюме блок з контактами, а де записаний досвід роботи. Саме слово «резюме» всередині файлу також можна не писати.
6. Кардинально змінювати межі документа, застосовувати дуже дрібний шрифт чи щось інше, що перетворює резюме у документ, який складно фізично прочитати.

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

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

Ім’я кандидата

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

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

Не забувайте, що ім’я треба скрізь писати однаково: в резюме, імейлах, профілі LinkedIn.

Контакти

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

Що варто там написати:

1. Номер телефону у міжнародному форматі, особливо якщо кандидат шукає роботу за кордоном. Можна не давати перелік усіх месенджерів. Рекрутери ефективно можуть знайти, куди написати спеціалісту.
2. E-mail. Зараз мало хто телефонує напряму кандидату. Передусім рекрутер з фахівцем буде спілкуватися письмово там, де був відгук на вакансію. Наприклад, Djinni, LinkedIn. Пошта також потрібна, щоб, наприклад, надіслати у календар запрошення на співбесіду. Тож у період пошуку роботи перевіряйте періодично скриньку, бо там може чекати запрошення на інтерв’ю.
3. Додайте Skype ID, якщо розумієте, що співбесіди будуть, найімовірніше, онлайн. І це буде альтернативним джерелом зв’язку, якщо з людиною більше ніяк зв’язатися не можна.
4. Місто і країна, де кандидат фізично перебуває і де він шукає роботу.
5. Чи готовий кандидат до релокації. Світ глобалізується, вакансії можуть приходити з будь-яких куточків світу, тому цей рядок стає важливим.
6. Тип працевлаштування. Наприклад, віддалена робота чи позначка, що спеціаліст готовий працювати в офісі.
7. Дозвіл на роботу. Якщо кандидат шукає роботу в іншій країні та вже має відповідний дозвіл чи робочу візу, то це теж можна вказати прямо в резюме.
8. У цей же розділ можна додати посилання на LinkedIn, портфоліо чи GitHub, якщо ви дизайнер чи програміст.

Що не варто сюди додавати:

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

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

Фотографія

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

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

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

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

Якщо ж кандидат додає фотографію у резюме, то варто дотримуватися певних правил:

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

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

Назва посади

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

Особливо це актуально для кандидатів:

1. Які шукають першу роботу і в їхньому резюме ще немає записів про конкретні посади.
2. Які змінюють професію. Наприклад, кандидат працював бухгалтером, потім пройшов IT-курси. Після їх закінчення подав резюме на IT-вакансію, але не вказав у резюме, що він тепер розглядає позиції за новою спеціалізацією. Навіть якщо у резюме буде запис про закінчення курсів, роботодавець може не зрозуміти, яку посаду шукає кандидат, якщо він це не вказав у резюме. Найімовірніше, йому і далі будуть пропонувати бухгалтерські позиції.
3. Які мають широкий вибір професій і напрямів. Якщо в резюме одночасно поєднується досвід роботи на різних посадах. Наприклад, кандидат працював Java Developer і Project Manager. У такому разі роботодавець може не знати, яку саме з посад запропонувати і який пріоритет має сам кандидат.

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

Не забувайте вказувати в посаді предметну галузь. Не пишіть саме слово «менеджер» чи «керівник відділу». Додавайте предметну галузь: менеджер з маркетингу; керівник відділу технічної підтримки.

Зверніть увагу, що англійською в посаді заведено писати всі головні слова з великої літери: IT Recruiter (а не It recruiter), Head of Digital Marketing (а не Head of digital marketing чи Head Of Digital Marketing). Це деталь, яка не вплине на рішення роботодавця, але добре, якщо кандидат знає, як узвичаєно писати його власну посаду.

Навички

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

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

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

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

1. Головні напрями роботи та загальний досвід: 5 years in product management.
2. Технічні інструменти та програми, за допомогою яких виконуєте свою роботу: 1C, Adobe Photoshop, Mailchimp, Excel.
3. Перелік мов програмування, з якими бажаєте працювати у майбутньому.
4. Сертифікати чи ліцензії, якщо вони необхідні для допуску до роботи.
5. Загальноофісні навички. Особливо програмісти чи дизайнери раніше писали просто перелік технічних систем та абревіатури. Зараз ситуація змінюється, і на загальні та менеджерські навички роботодавці теж звертають увагу. Наприклад, communication, teamwork, leadership тощо. Періодично читайте вакансії та зауважуйте, які саме навички роботодавці в них вказують.
6. Іноземні мови, особливо якщо кандидат шукає роботу за кордоном, планує працювати з мультинаціональними командами чи певна мова є однією з головних вимог вакансії: English — Upper-Intermediate.

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

Зверніть особливу увагу:

1. Розділ Навички ми пишемо з погляду майбутнього. Тобто тут не буде переліку абсолютно всього, що кандидат знає та вміє. Тут буде перелік, який передусім знадобиться вашому майбутньому роботодавцю. Через вдале розташування роботодавець відкриває резюме та відразу бачить найголовніше. З практики знаю, що з якісним розділом Навички потім наймачі менш прискіпливо дивляться на досвід роботи. Тому цим розділом ви можете керувати та балансувати інформацію, щоб вона вигідно підкреслювала ваші сильні професійні сторони.
2. Якщо у кандидата взагалі немає досвіду роботи, то у цьому розділі варто написати власні побажання щодо майбутньої роботи. Тобто пишете, з якими напрямами бізнесу готові працювати, з якими системами та технологіями, з якими командами тощо. Можна зазначити технології, які вивчали на курсах чи в університеті. Це дасть роботодавцю орієнтири та розуміння, у якому напрямку рухатися та що пропонувати.
3. Якщо у вас забагато досвіду, то обирайте, з чим вам найбільше хочеться працювати у майбутньому. Обирайте найголовнішу та найсучаснішу інформацію. Не пишіть тут те, що вже неактуально для вашої професії. Перелік всіх технологій, з якими працювали, напишете у розділі Досвід роботи. А тут можна обирати та фокусувати інформацію роботодавця на потрібних моментах.
4. Цей розділ ви можете змінювати під потреби конкретної вакансії. Якщо у вас різносторонній досвід та інтереси, то тут дуже зручно адаптувати інформацію, щоб показати роботодавцю передусім найважливіше.
5. Старайтеся не писати довгих фраз. Словосполучення в 1-3слова будуть оптимальним варіантом. Можна подивитися в LinkedIn, як там пропонують писати про навички у відповідному розділі. Ця інформація має добре зчитуватися і не містити нагромадження.

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

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

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

Досвід роботи

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

Структура розділу може бути такою:

1. В одному рядку пишемо дати роботи — початок і закінчення. Місяць словом, яке можна написати скорочено, рік повністю цифрою. Можна писати весь період роботи у компанії, об’єднавши всі посади та переходи між посадами в одне ціле. Зазвичай так роблять, коли терміни роботи на кожній із посад був невеликий чи позиції нерелевантні роботі, яку кандидат шукає. Або можна написати окремими датами кожну із посад. Так роблять, якщо людина багато років працювала тільки в одній компанії та зросла, наприклад, з рівня Junior до рівня керівника команди чи компанії.
2. Далі пишемо назву компанії. Зазначайте загальновідому назву, а не назву юридичної особи. Можна дописати локацію, тобто місто і країну, де саме ви працювали, особливо якщо це компанія, яка має офіси по світу.
3. Пишемо назву посади. Не забувайте загальні принципи про предметну галузь і ринкову назву. Якщо всередині компанії вам вигадали назву посади, яку більше ніде на ринку праці не розуміють, то таку назву можна змінити.
4. Ці три записи можна виділити жирним шрифтом, щоб і розмежування було, і інформація краще зчитувалася. Збільшувати розмір шрифту, застосовувати курсив чи підкреслення не потрібно. Не треба тут писати загальну інформацію про компанію, сайт колишнього роботодавця чи додавати логотипи компаній. Між місцями роботи залишайте проміжок простору в один чи два рядки. Таким чином графічно інформація зчитається якісно.
5. Далі записуємо під кожною назвою компанії та посади два розділи: Обов’язки та Досягнення. Саме слово «досягнення» можна написати.
6. В Обов’язках варто вказати списком суть роботи. Тип завдань, які ви виконували найчастіше. Завдання, які забирали найбільше часу. Завдання, які найбільше вам подобалися. Напишіть перелік технологій, які використовували. Для кого виконували цю роботу та про її вплив на бізнес роботодавця. Про клієнтів, з якими співпрацювали, та команду. Про принципи, яких дотримувалися.
7. У Досягненнях напишіть списком по пунктах про результати роботи. Про те, чим пишаєтесь. Добре, якщо тут є цифри чи показники, які кандидати мають право розкривати. В жодному разі не пишіть тут конфіденційну інформацію. І жоден роботодавець на співбесіді не має права просити її розкривати. Можна додати приклади ситуацій. Роботодавцям подобаються взірці рішень і бізнес-ситуацій, які кандидат вирішував сам чи в команді.

Розділ Досвід роботи займає найбільше місця в резюме, тому:

1. Старайтеся, щоб кожен пункт не займав більше як 1-2 рядки.Бо інформація буде гірше зчитуватися.
2. Для кандидатів Junior-Middle рівнів достатньо написати приблизно по 3-5 пунктів.Кандидати рівнів Senior-Team Lead можуть написати більше пунктів до кожного місця роботи.
3. Кожен пункт можна написати з використанням маркерів. Нумерувати їх не потрібно, бо цифри будуть відвертати увагу. Оберіть один тип маркерів для всього резюме, щоб за допомогою них структурувати інформацію.
4. Не забувайте форматувати та вирівнювати текст, щоб оптимально використовувати місце в резюме.
5. Ми пишемо Досвід роботи у хронологічному порядку, де на першому місці вгорі під розділом Навички буде теперішнє чи попереднє місце роботи. І внизу буде найдавніше місце роботи.
6. Особливу увагу роботодавці звертають на місця роботи, які були в межах останніх 5–10 років.У різних сферах це по-різному, бо тут має значення швидкість змін і вплив технологій. Не варто в резюме детально писати про методи роботи, які вже ніхто не використовує. Якщо ви вже давно не Junior та у вас досить багато років досвіду, то біля найдавніших і нерелевантних місць роботи можна залишити тільки дати, назву компанії та посади. Списки з Досягненнями та Обов’язками можна видалити. Таким чином ви сфокусуєте увагу роботодавців на найважливішому та цікавому для вас і збережете місце для цінної інформації про ваш досвід.

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

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

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

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

Якщо ви не працювали в жодній компанії, а, наприклад, навчалися на IT-курсах і розробляли сайти для бізнесу друзів, то в резюме ви можете записати так:

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

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

Освіта

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

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

Зараз сюди можна додати:

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

Записати можна так, усе в хронологічному порядку:

2020 Назва курсу, спеціалізація, локація, де він проходив чи інші суттєві деталі.
2019 Конференція, локація, де вона проходила чи інші суттєві деталі.
2018 Університет, спеціалізація, диплом магістра чи бакалавра.

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

Інші розділи резюме

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

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

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

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

Форматування резюме

У процесі роботи не забувайте зберегти сам файл. Коли ви виконаєте всі пункти, зробіть Ctrl+A, правою клавішею оберіть «Параграф» і поставте нулі у розділі Spacing. Таке форматування допоможе зробити так, щоб інформація не була розтягнутою на багато сторінок. Перегляньте весь документ. Зробіть відступи та порожні рядки між головними блоками та місцями роботи. Красиво все вирівняйте і відформатуйте. Покажіть майбутньому роботодавцю, що вмієте працювати з документами та програмами. Я думаю, що Word — це найлегша програма, з якою вам доводиться працювати.

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

На завершення

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

Якщо ви прочитати статтю, попрацювали з нею, зробили резюме, але маєте складнощі чи питання, будь ласка, вільно пишіть мені на пошту: yulia@shyshenko.com. Але не забудьте вказати у темі листа, що ви опрацювали статтю про резюме на DOU. Напишіть свою ситуацію, пояснення, запитання та не забудьте прикріпити сам файл з резюме, якщо у вас питання саме до нього.

Стаття підготовлена ексклюзивно для DOU. Якщо хочете опублікувати матеріал на іншому ресурсі чи сайті, будь ласка, отримайте дозвіл автора yulia@shyshenko.com.

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

Дякую, що прочитати та опрацювали статтю. Я бажаю, щоб вона дала вам найкращі можливості для кар’єри.

Щоби не пропустити нові статті Юлії Шишенко — підписуйтеся на неї у телеграм-боті Стрічки DOU.

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

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

Для кого ця стаття

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

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

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

Три кити розробки власного продукту

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

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

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

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

Розуміння і використання принципів тайм-менеджменту

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

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

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

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

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

Формування і досягнення цілей

Щоб досягти цілі, спершу треба її визначити. Для цього:

• Почни з формування конкретних цілей.
• Розбивай масштабні цілі на менші, які можна швидше досягти. Це більше стосується завдань, але спробуй перенести й на цілі: наприклад, ціль «отримувати 100 замовлень на місяць» можна почати зі «збільшити кількість відвідування сайту до 100 людей за день до 15 грудня», «отримати перше замовлення до 20 грудня» тощо. Для реалізації кожної з них легше спланувати потрібні завдання та їхні дедлайни.
• Обов’язково вказуй дедлайн кожної цілі. Наприклад, «зібрати 10 підписників до 15 грудня», «отримати перше замовлення до кінця року».
• Плануй критерії, при яких ціль буде вважатися виконаною. Якщо є мета залучити перших 10 підписників до 1 грудня, то критерій оцінки буде один: кількість підписників; тоді як критеріями готового MVP буде, зокрема, запущений вебсайт, наповнені сторінки, протестована мобільна і комп’ютерна версії тощо.
• Записуй свої плани. Краще не надіятися на пам’ять, бо так легко упустити щось важливе.
• Плануючи шлях до цілі, подумай про ймовірні проблеми, які можуть виникати на всіх етапах діяльності, і шляхи їхнього розв’язання.

Визначення пріоритетів

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

• Складай список справ на квартал, місяць, день тощо.
• Розділяй великі завдання на менші й плануй часові рамки для кожного з них («затвердити макет головної сторінки до кінця місяця»).
• Розділяй завдання за пріоритетністю. Спочатку заверши найважливіші задачі, тоді переходь до менш пріоритетних.
• Фокусуйся на одному завданні, а не на кількох відразу. Так значно ефективніше та швидше можна його виконати.
• У кінці визначених періодів аналізуй виконання планів. Краще це робити щодня, пізніше можна перейти на більші відрізки часу.

Робота з факторами, які відвертають увагу

Що я раджу:

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

Реальне оцінювання часу

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

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

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

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

Розуміння і застосування концепції MVP

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

У таких випадках хочеться сказати собі: «Попустися». Але я сформулюю краще: «Запусти свій проєкт як MVP». Шкода, що я почав застосовувати такий підхід зовсім недавно, але ж таки почав. Тож далі поговоримо про суть MVP і його практичне використання.

Minimum viable product (MVP) — це первинний продукт/сервіс із мінімальним набором основних функцій, створений при найменшихзатратах часу і фінансів. Призначення MVP — запропонувати основну ідею продукту аудиторії ще до повної реалізації усіх функцій і зібрати всю необхідну інформацію для подальшого розвитку.

Якщо скоротити ідею MVP до п’яти слів, то вийде таке:

MVP — це максимальна цінність при мінімальних зусиллях.

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

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

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

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

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

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

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

Далі сталося багато всього: я створив телеграм-чат, присвячений Instagram, і запрошував людей із сайту приєднатися до нього (кількість користувачів згодом досягла 2,5 тисячі). Знайшов багато однодумців. Продавав рекламу. Розробив ще одну версію сайту зі своїм API. Зняв усі ліміти з кількості лайків для одного сервісу за окрему плату. Розробив свого бота для завантаження публікацій з Instagram (фото, відео, IGTV, тексти), який зараз збирає понад 80 тисяч активних користувачів на місяць. А тепер працюю над монетизацією бота.

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

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

Аналіз проєкту

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

Гаразд, та для цього тобі самому потрібно краще ознайомитися з власним продуктом. Для цього я пропоную розбити аналіз на три етапи:

1. Початковий аналіз проєкту (формування гіпотез).
2. Аналіз сприйняття ідеї (погляд збоку, відгуки, рекомендації).
3. Аналіз подальшого розвитку.

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

Початковий аналіз проєкту

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

• Яка цінність мого продукту? Яку проблему він вирішує?
• Хто цільовий користувач? Чи достатньо велика цільова аудиторія?
• Як я буду шукати цільових користувачів?
• Хто є моїми конкурентами? Які їхні сильні та слабкі місця? Чим я від них відрізняюся?

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

Вдалося? Що ж, можна з чистою совістю складати план запуску MVP.

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

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

Аналіз сприйняття ідеї

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

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

Для об’єктивності навчися ставити правильні запитання! Можна спитати: «Вам подобається ця ідея?», але тоді ризикуєш почути неправду або ж неповну правду, адже ніхто не бажає опинитися в незручному становищі через критику чиєїсь мрії. Усім рекомендую прочитати книгу Роба Фітцпатріка «Спроси маму. Как общаться с клиентами и подтвердить правоту своей бизнес-идеи, если все кругом врут?» (перекладу українською не знайшов). Шкодую, що дізнався про цю книгу відносно недавно.

Аналіз подальшого розвитку

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

• А що далі?
• Чи зможу я самостійно просувати продукт?
• Чи потрібно мені залучити інших людей?
• Чи достатньо мені ресурсів і чи буде потрібен інвестор?

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

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

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

На завершення

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

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

Щоби не пропустити нові статті Андрія Балія — підписуйтеся на нього у телеграм-боті Стрічки DOU.

Я програмую близько 11 років, за цей час перепробував кілька мов, від С++ до JS. Зараз я займаю посаду Senior Developer в ELEKS. Ні, це не сповідь анонімного кодоголіка і не автобіографія. Це всього лише спосіб вкласти в голові свої думки і, можливо, дати поживу для роздумів тим, хто прочитає статтю.

Десь я вже це бачив. Чому мови програмування описують одні й ті самі сутності

Чим взагалі за своєю суттю є мова програмування? Це спосіб сформулювати свій потік свідомості у форму, доступну для розуміння комп’ютера і побратимів за професією, яким доведеться вивчити чимало нових лайливих слів, аналізуючи отриманий продукт. (Рідко трапляється код, під час читання якого плачеш від щастя, якщо таке взагалі буває. Набагато частіше плачеш з інших причин.)

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

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

Так само і з сутностями в програмуванні. Практично будь-яка мова містить ті ж змінні, цикли, функції... Тільки називаються вони по-різному. Все інше — лише надбудови над базовим функціоналом. Понад те, попри різницю в імплементації та принципах роботи, сучасні мови мають приємну тенденцію тирити одна в одної концепції, адаптуючи їх під свої потреби. Подобаються лямбди в C#? Найімовірніше, оціните і стрілкові функції в JS. WriteProcessMemory — твій найкращий друг, милий хакере? Ласкаво просимо в pinvoke C# або Frida.js. Подобається Nest.js? Думка «ух ти, десь я це бачив» не раз наздожене під час вивчення нових версій Angular.

Переваги програміста-поліглота

За весь час, що я програмую, встиг спробувати багато варіантів. Починав із C/C++, експериментував із реверс-інжинірингом (що потребує хоча б базового розуміння асемблеру), потім влаштувався працювати гейм-розробником на Unity3D, де захопився C#. Відтак почав використовувати PHP і JS, добрався до різних видів SQL/NoSQL, трошки колупав ActionScript, AutoHotkey, Lua тощо. Найбільше з того зачепила JavaScript, тож на ній чого тільки не робив: від розширень Chrome до Electron, від сайтів до Frida.js (фреймворк для інжекту коду в нативні аплікації).

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

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

Рейтинг мов програмування 2020, DOU

Чому я вивчаю та використовую різні мови

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

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

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

2. Можна підглянути цікаві підходи й за наявності «прямих» рук застосовувати їх і в інших мовах. Наприклад, я намагався використовувати щось схоже до LINQ у JS, поки не з’явилися оті всі filter, map тощо.

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

Загалом на моїх останніх проєктах це є актуальною темою. То проєкт із legacy-кодом на паскалі, то потрібно внести невеликі виправлення у код на Python, то бек на Go. І не завжди легко догукатися до того, хто той код розробляв, щоб зрозуміти, що там взагалі відбувається.

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

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

6. У срачах з іншими програмістами можна тролити більш аргументовано.

7. Колеги не зможуть пропхати фішки в стилі «це не можна реалізувати в цій мові». Можна.

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

Звичайно, не все так ідеально.

Недоліки

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

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

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

4. Якщо немає постійної практики, починаєш забувати, як воно працює. Так, це можна відносно швидко відновити, але все одно поріг входження вищий. Наприклад, я штрикав Angular ще у другій версії, але коли потрібно було зробити на ньому тестове та loopback (про який я мало що чув), це зайняло приблизно 6–7годин для більшої частини функціоналу.

5. Best practices у різних мовах часто мають специфічні для тієї мови особливості. Їх вивчення теж займає багато часу й іноді конфліктує з попереднім досвідом.

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

Мої принципи вивчення мов програмування

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

Алгоритміка та псевдокод

Чудова стартова точка для вивчення. Ще непогано підходять старі мови без зайвих наворотів (у школі, наприклад, нам давали Pascal). Чому це хороша штука? Тому що базові принципи вивчаються без прив’язки до конкретного оточення й мови. Для чого мені знати, як буде поводитись цей шматок коду залежно від архітектури процесора, якщо я тільки почав вивчати програмування? Навіщо мені знати особливості реалізації, якщо вони різняться від платформи до платформи? Правильно, тому що це цікаво, але про це замислюєшся пізніше. Спочатку потрібно подолати цей дикий крик у голові: «Що за змінні? Навіщо ми пишемо перед ними var/int/blah-blah-blah? Що тут взагалі відбувається?».

Вичленовування базових принципів

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

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

Збереження даних:

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

Організація і перевикористання коду:

• функції;
• класи;
• бібліотеки (модулі, фреймворки, платформи тощо);
• репозиторії.

Базові конструкції:

• цикл (while, for, вбудовані методи, як-от .filter, .map тощо);
• умова (if, switch, тернарки).

Оператори:

• арифметичні (+ - =), включаючи інкремент-декременти;
• бітові (& | ^);
• логічні (||, &&).

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

Знання патернів, архітектури, принципів

Це взагалі універсальна штука, найчастіше без прив’язки до конкретної мови. Всі ці SOLID, MVC, Singleton’и — попри підгонку під конкретну мову, як правило, під капотом несуть ті ж ідеї. Їх не потрібно заучувати, але корисно знати. Втім, як показує практика, часто ви можете не знати навіть назви конкретного патерну, але при цьому чітко розуміти його принципи.

Не вчіть кілька мов одночасно на початку

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

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

Не соромтеся шукати потрібні вам речі й писати на той же Stack Overflow, Toster або Reddit. 50 осіб з вас посміється, та один дасть потрібну пораду. Взагалі не соромтеся визнавати, що чогось не знаєте. Просто не забувайте додавати, що готові й можете це дізнатися.

Цікаве завдання і реалізація різними мовами чи стеком технологій

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

Кожна нова мова — це інструмент

Не намагайтеся викруткою зашити рану на руці, для цього є моло... скальпель. Я хотів сказати голка з ниткою. Так і мови. Для математичних операцій широко розрекламований Haskell, для роботи з пам’яттю — C++ або Rust (або що там нині в тренді), для вебу — JS & компані. Правда, іноді ефективніше реалізувати задачу мовою, яка для цього не пристосована, але добре знайома.

Слухати навіть менш досвідчених розробників

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

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

Чому варто вчити різні мови

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

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

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

Щоби не пропустити нові статті Антона Трофімова — підписуйтеся на нього у телеграм-боті Стрічки DOU.

Другого листопада за ініціативою 11 депутатів «Слуги народу» і ОПЗЖ у Верховній Раді було зареєстровано проєкт закону 4303«Про стимулювання розвитку цифрової економіки в Україні», більше відомий як законопроєкт від Мінцифри про Дія Сіті. Незабаром 18 листопада було внесено альтернативний проєкт закону 4303-2«Про стимулювання розвитку сфери інформаційних технологій в Україні», ініційований групою з 18 депутатів від «Голосу», «Європейської солідарності», «Батьківщини», «Слуги народу» і «За майбутнє». Для простоти сприйняття у цій статті я називатиму останній просто законопроєктом від «Голосу».

Законопроєкт від «Голосу» — це follow-up на законопроєкт від Мінцифри. Він повторює більшість норм останнього, але є краще структурованим, містить багато уточнень там, де їх бракувало.

У разі ухвалення будь-якого з цих законів IT-індустрію чекають великі зміни, а тому я пропоную без популізму розглянути обидва в деталях. А оскільки DOU є спільнотою IT-спеціалістів, то й аналізувати запропоновані законодавчі норми будемо з позиції рядових програмістів, тестувальників тощо. Отже, що змінить Дія Сіті для працівників IT-галузі?

Що таке Дія Сіті

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

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

Однією з умов резидентства є середня зарплата по компанії 1400 доларів США. Компанія, яка наймає забагато джуніорів, фактично не зможе стати резидентом Дія Сіті. Інша умова — компанія повинна мати не менше ніж 9 працівників.

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

Гіг-працівники та гіг-контракти

Обидва законопроєкти передбачають, що резидент Дія Сіті має право залучати працівників на підставі трудових договорів, підрядників, в тому числі ФОПів, а ще так званих гіг-працівників на підставі гіг-контрактів.

За законопроєктом від Мінцифри гіг-працівник

«зобов’язується особисто виконувати роботу, визначену резидентом Дія Сіті, що складається із завдань (гігів), проєктів та розпоряджень резидента Дія Сіті чи його гіг-працівників».

За законопроєктом від «Голосу» гіг-виконавець

«зобов’язується особисто виконувати роботу або надавати послуги у сфері IT, визначені резидентом Дія Сіті, що складаються з окремих завдань (гігів) резидента Дія Сіті, серії завдань чи їх сукупності (проєкт)».

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

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

Чим же гіг-контракт відрізняється від договору з ФОПом? У гіг-контракті може встановлюватися робочий час і час відпочинку. За законопроєктом від Мінцифри компанія не має права штрафувати гіг-працівника, крім компенсації за шкоду, завдану працівником майну роботодавця. В останньому випадку сума щомісячних відрахувань не може перевищувати 20% винагороди.

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

«Тривалість перерви протягом дня, щотижневого відпочинку, оплачуваної щорічної відпустки гіг-працівника, а також порядок оплати днів відпустки встановлюються за домовленістю сторін в гіг-контракті» (стаття 33, частина 3).

Тобто нічого нового, якщо порівнювати з ФОП-моделлю, гіг-контракт не привносить. Фактично ваша відпустка може бути навіть 5 днів, якщо роботодавець протисне вписання такої норми в гіг-контракт, а всі розмови про те, що тепер в IT-спеціалістів з’явиться гарантована відпустка — фікція.

«Забороняється припиняти гіг-контракт у період тимчасової непрацездатності гіг-працівника, крім випадків тимчасової непрацездатності, яка триває більше одного місяця» (стаття 34, частина 6).

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

Щодо відпусток і соціальних гарантій у «Голосу» жодної конкретики.

«Законом можуть визначатись окремі особливості укладення гіг-контрактів чи додаткові гарантії для гіг-виконавців».

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

Договір про непереманювання

Законопроєкт від Мінцифри вводить поняття «договір про непереманювання». Згідно зі статтею 40 укладення такого договору зобов’язує

«утримуватися від спонукання усіх або певних клієнтів, працівників, гіг-працівників або підрядників іншої сторони до припинення відносин з резидентом Дія Сіті та від спонукання працівників, гіг-працівників або підрядників резидента Дія Сіті до укладення гіг-контрактів, трудових договорів (контрактів) або цивільно-правових договорів з іншими особами».

Якщо переманювання таки сталося, порушник зобов’язаний відшкодувати збитки постраждалому резиденту Дія Сіті та сплатити штраф, передбачений договором.

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

У законопроєкті від «Голосу» жодних договорів про непереманювання немає.

Договір про утримання від вчинення конкурентних дій

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

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

«Нас не прийняли в Дія Сіті, а ми стали єдинорогом!»

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

Навіть якщо ваш стартап взяли в Дія Сіті, то — сюрприз — йому дають лише 6 місяців на те, щоб вийти на зарплату 1400 доларів, та рік, щоб вийти на кількість працівників у 9 осіб (стаття 13, частина 5 законопроєкту від Мінцифри). Так що можна сказати, що так звані винятки для стартапів — це бутафорія.

Законопроєкт від «Голосу» встановлює чіткі критерії прийняття стартапу в Дія Сіті замість суб’єктивного рішення, передбаченого законопроєктом від Мінцифри. Стартапу дають два роки з моменту реєстрації на те, щоб почати відповідати усім критеріям резидентства, як-от зарплата 1400 та 9 працівників, інакше — виключення з Дія Сіті.

Авторські та майнові права

Законопроєктом від Мінцифри передбачено зміни в Цивільний кодекс, за якими

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

У співробітника виникають авторські права, у роботодавця — майнові. Тут все логічно.

Гарантії резидентам

«На всіх резидентів Дія Сіті поширюється система державних гарантій захисту інвестицій, передбачена законодавством України про інвестиційну діяльність та режим іноземного інвестування» (стаття 47, частина 1 законопроєкту від Мінцифри).

Без коментарів.

Висновок

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

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

Щоби не пропустити нові статті Дмитра Скорохода — підписуйтеся на нього у телеграм-боті Стрічки DOU.

Вітаю. Мене звати Богдан. Працюю в ІТ останні 9 років, 8 з яких зі Scrum. Спочатку був розробником, потім перейшов на позицію Scrum Master. Протягом останніх п’яти років працював як Product Owner/Product Manager у продуктових компаніях в Україні, Польщі, Німеччині. Сертифікований Scrum Master (PSM III) та Product Owner (PSPO III), нещодавно склав іспит для отримання ліцензії Professional Scrum Trainer від Scrum.org.

Стаття присвячена основним змінам у новій редакції Scrum Guide. Передусім матеріал буде цікавий людям, що працюють у Scrum-командах чи співпрацюють із ними.

Цього року Scrum виповнюється 25 років. Саме стільки часу минуло, відколи Кен Швабер і Джефф Сазерленд уперше формально презентували його на конференції OOPSLA 1995 року.

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

Зміни у Scrum: чому це важливо

Наприкінці цього літа Кен Швабер анонсував у своєму блозі масштабну для Scrum-світу подію: вихід оновленої версії Scrum Guide. Новий документ обіцяли зробити lean and focused і зменшити до 13 сторінок (попередня англомовна версія містила 19). Подія, безперечно, важлива одразу з двох причин.

Перша: зміни у Scrum Guide — рідкісна річ. Востаннє документ змінювали восени 2017 року. Зазвичай нова версія з’являється не частіше ніж раз на два-три роки. Друга: останні зміни зачепили практично всі секції документа, водночас значною мірою це були спрощення та узагальнення, а не уточнення, як зазвичай. Особливо тішить, що світ побачила не початкова версія документа, а виправлена, в котрій були враховані відгуки Scrum-спільноти.

18 листопада відбулась офіційна презентація оновленої версії документа. Звісно, не така масштабна, як презентація нового iPhone, зокрема через те, що Zoom вміщував максимально 1000 користувачів в одній нараді. Окрім привітання та загального тлумачення змін від співавторів (тішить, що дідусі ще живі-здорові), можна було взяти участь у воркшопах та Q&A-сесіях, де пояснювали нові зміни та їхнє прикладне значення. Повний запис трансляції доступний за посиланням.

Зліва — Кен Швабер; справа — Джефф Сазерленд

Що змінилося

Нижче пропоную ознайомитись з основними змінами в документі.

Введення нового поняття Commitment, кристалізація в ньому Sprint Goal та Definition of Done

Попередня версія документа була наскрізь пронизана згадками про Definition of Done та Sprint Goal. Про останню йшлося аж 27 разів. І не дивно, бо це суттєво впливає на всі Events та Artifacts. Проте жодне з понять не було формально визначеним, воно нікуди не належало. У Scrum-спільноті неодноразово лунали пропозиції формалізувати їх, як приклад — долучити до списку Artifacts.

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

Commitment для Product Backlog — Product Goal.

Commitment для Sprint Backlog — Sprint Goal.

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

Commitment для Increment — Definition of Done.

Кожен інкремент зобов’язаний відповідати всім стандартам якості для продукту. Якщо увесь інкремент чи навіть одиничний елемент Product Backlog не є done, то його не можна ані релізити, ані презентувати на Sprint Review.

Введення нового поняття Product Goal

Нове поняття Product Goal є, на мою думку, найбільш цікавою зміною з усіх. Цитуючи Scrum Guide: «Ціль продукту описує майбутній стан продукту, який може слугувати скрам-команді метою для планування. Ціль продукту висловлена у беклозі продукту. Решта беклогу продукту з’являється, щоб визначити, „що саме“ буде виконувати ціль продукту».

Якщо простіше, то у попередній версії згадувалося, що кожен Increment — це крок у напрямку до певного кінцевого бачення чи цілі. Кен і Джефф вважають, що саме поняття бачення є занадто розмитим, а Scrum передусім є інструментом досягнення конкретних цілей. Звідси й формалізація поняття Product Goal. Згідно із задумом авторів, Product Backlog тепер має будуватися не на абстрактному баченні майбутнього продукту, а на конкретних осяжних цілях.

Scrum Guide умисно не тлумачить жодних додаткових питань довкола цього нововведення, а питань виникає чимало:

• Як саме краще формалізувати Product Goal та моніторити прогрес до неї?
• Наскільки амбітною має бути ціль, щоб шанси її досягти були максимальними?
• Як саме треба оновлювати ціль і Product Backlog, якщо наявна ціль була досягнута (відкинута)?
• За допомогою яких технік досягти прозорості Product Goal?

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

Зміни в Scrum Team та акцент на її єдності

Зникло базове поняття «ролі» у скрам-команді, замість неї маємо «сферу відповідальності». Поняття Development Team теж замінили на більш просте — Developers. Прибрали й вимоги стосовно кількості Developers у команді. Раніше було чітко вказано, що для оптимальної співпраці команда розробки має складатися із 3-9 людей.Зараз же зазначено лише те, що Scrum Team зазвичай складається з 10 чи менше осіб. Але це як рекомендація.

У новій версії автори ставили собі за мету елімінувати концепцію, що сформувалася у багатьох Scrum-командах, а саме: «команда в команді» (Development Team y Scrum Team). Нерідко це спричиняло розділення Scrum-команди на «ми» і «вони» між Development Team та Product Owner. Це супроводжувалося взаємними звинуваченнями, було небажаним і контрпродуктивним.

Саме тому формулювання та опис сфер відповідальності у Scrum Team змінили, аби підкреслити, що є лише єдина команда, яка працює над спільними цілями й має три складники: Product Owner, Scrum Master та Developers. Певно, ключовою зміною в цьому контексті є те, що раніше за створення Increment’y відповідала тільки Development Team, а тепер це відповідальність всієї Scrum Team, а не лише розробників.

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

Зміни у проведенні Sprint Planning

На додаток до двох наявних логічних частин Sprint Planning Whatі Howвводять нову частину Why, що фокусуватиметься на Sprint Goal. Порядок буде такий: Why → What → How.

Ідея полягає в тому, що під час частини Why Product Owner має запропонувати, як саме продукт може збільшити цінність, яку приносить, упродовж поточного спринту. Далі вся Scrum Team має визначити Sprint Goal, що чітко пояснює стейкхолдерам, чому саме цей спринт є для них цінний.

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

Менш розпорядчий та більш доступний

Як зауважили автори, упродовж останніх років Scrum Guide містив усе більше вказівок. Версія 2020 має на меті повернути Scrum до першоджерела, коли він був minimally sufficient framework.

Наприклад, було вилучено або спрощено такі частини документа:

• повністю прибрали і без того необов’язкові три питання для Daily Scrum;
• зменшився перелік необхідних атрибутів для елементів Product Backlog;
• вимога додавати найбільш критичні речі зі Sprint Retrospective до наступного Sprint Backlog стала рекомендацією;
• розділ, що стосується скасування спринту, скоротили з 4 абзаців до 1 речення тощо.

З документа вилучили надлишкові та занадто складні мовні конструкції. Крім того, прибрали останні згадки про ІТ (testing, system, design, requirement тощо), оскільки за ці 25 років Scrum вийшов далеко за межі ІТ і успішно застосовується у багатьох інших сферах життя. Як і обіцяли, новий Scrum Guide помістився усього на 13 сторінках.

Оновлена версія Scrum Guide вже доступна як англійською, так і українськоюмовами.

Замість висновків

Радикальних змін у практичному застосуванні Scrum’у не передбачають. Найбільших труднощів, певно, додасть введення поняття Product Goal та пошук оптимальних технік для її опанування вже в контексті конкретного продукту/команди. Доведеться більше часу та уваги приділити плануванню спринту.

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

Як і раніше, перші місяці після виходу нової версії Scrum Guide будуть схожими на перші місяці після випуску відеогри: люди ділитимуться досвідом та допомагатимуть одне одному подолати перепони; знайдуться баги та експлойти, котрі ляжуть в основу нової версії. Може, навіть буде як з Diablo II: знайдеться спідранер, котрий покаже, що всю гру можна пройти менше ніж за годину.

І хоча частину про те, що Scrum є «Simple to understand. Difficult to master» прибрали з нової версії документа, проте таким Scrum і залишається. І навіть суттєві зміни та спрощення цього не змінять.

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

Щоби не пропустити нові статті Богдана Онищенка — підписуйтеся на нього у телеграм-боті Стрічки DOU.

За роки роботи, отримав всебічний досвід в проєктному менеджменті, бізнес-аналізі, продакт-менеджменті, систематизував власну управлінську взію на питання створення і впровадженя фреймворку роботи ІТ-проєктів. Ця візія дає можливість оцінювати проєктні управлінські процеси за підходом «360 градусів» та провадити внутрішню консалтингову експертизу з різних питань.

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

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

Підхід до створення універсального проєктного фреймворку

Для управлінця (РМ/ВА/DM/Prg.M тощо) робочий фреймворк передусім є інструментом ефективної організації та розуміння роботи. За весь час існування ІТ-галузі у світі було створено багато підходів до управління проєктами. Більшість із них базуються на технічних аспектах роботи команд. Наша мета — сформувати та розкрити бачення на створення універсального підходу до розробки фреймворку з погляду управління і цінності, яку може принести цей процес проєкту і клієнту, а також на сам фреймворк як управлінський інструмент. Розгляньмо запропонований авторський концепт універсального проєктного підходу (Рис. 1).

Робочий фреймворк як спосіб ефективної організації проєктної діяльності має відповідати на три запитання:

1. Навколо чого ми об’єднуємось як команда? Це цінності (project core value)відповідно до особливостей співпраці з клієнтом.
2. Як саме наша команда планує втілити цінності в рамках проєктних цілей? Це організація основних компонентів командної роботи (framework core).
3. Як гнучко можемо контролювати проєктну діяльність на всіх рівнях управління, а також як швидко і легко можемо реалізувати необхідні проєктні зміни? Це адаптивність проєктної роботи.

Ці компоненти та характеристики — основа ефективного управління проєктною роботою. В основі створення фреймворку пропоную використовувати принцип єдності взаємодії всіх компонентів як цілісної системи:

Рис. 1. Концепт створення універсального проєктного фреймворку

Політики (project policies)

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

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

Принципи командної роботи (teamwork principals)

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

Структурований взаємозв’язок об’єктів проєктної роботи (project context diagram)

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

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

Показники ефективності, моделі делівері-процесу (Delivery model based on SDLC type and SDLC KPI’s)

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

Метрики оцінювання ефективності процесу делівері пов’язані із блоками активностей загального процесу роботи ІТ-команди (team workflow) і є джерелом важливої інформації для підвищення якості роботи.

Усі показники ефективності процесу делівері пропоную групувати так:

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

Усю сукупність показників далі розподіляємо не тільки за блоками активностей, а й за рівнями: проєктним, процесним і продуктовим. Такий аналітичний розподіл створює модель огляду показників ефективності делівері-процесу за принципом T-sharp model і є всеохопним за своєю дією. Отримані метрики ефективності також використовують для визначення і ліквідації вузьких місць у роботі.

Робота команди та її найкращі практики (Team workflow and Practices)

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

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

Структурна модель проєктних активностей і їхніх артефактів (Project activities structure model)

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

• налаштування проєктної комунікації;
• робота над продуктом (продуктова візія і функціональність);
• налаштування командної взаємодії;
• налагодження делівері-процесу і відповідності стандартам роботи клієнта;
• проєктне урядування.

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

Усі вищеперелічені компоненти проєктної діяльності поділяємо на дві великі групи (півсфери схеми моделі):

1. Ідеологічний базис (Ideology part) — основа меж взаємодії та розуміння проєктного контексту.
2. Імплементаційний базис (Implementation part) — детальне бачення операційної взаємодії.

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

Створення імплементаційної групи

Для впровадження фреймворку потрібно створити імплементаційну групу з такими ролями: програм-менеджер (Prg.M), делівері-менеджер (DM), проєктний менеджер (PM), бізнес-аналітик (ВА), архітектор (Arch.L), девелопмент-лід (Dev.L). Концепт її заснування має низку переваг:

1. Забезпечення широти експертних думок.
2. Централізоване створення і драйв необхідних ініціатив.
3. Формування внутрішнього консалтингового напряму роботи проєкту.
4. Контроль формування необхідної бази управлінського досвіду.
5. Створення джерела синергії взаємодії у проєктній команді.

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

1. SDLC KPI’s — описові таблиці та формули розрахунку.
2. Teamwork Principals — короткий та чіткий опис ідей принципів.
3. Project Policies & Basic Agreements, Team Practices — корпоративні або кастомні (спеціалізовані) під проєкт шаблони (templates) з описом застосування.
4. Project Data Context — контекстна діаграма з описом.
5. Team workflow — BPMN-діаграма з описом застосування.
6. Project Activities — структурна діаграма з описом (більше про це читайте у моїй попередній статті).

Усі деталізовані та описані графічно компоненти логічно згрупувати у комплексну схему для цілісного сприйняття. Розгортання такої деталізації має відбуватися навколо ядра проєктного фреймворку. Додатковий текстовий опис раджу збирати в одному інформаційному ресурсі (наприклад, Confluence).

Підтримка проєктного фреймворку (project framework maintenance) як один із видів проєктних активностей має свої особливості:

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

Основні складнощі при впровадженні

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

1. Навчання проєктних команд, які можуть мати фахівців із різноманітним досвідом проєктної роботи.
2. Формування єдиного бачення проєктних дійзгідно із фреймворком роботи. Створення синергії дій усіх учасників проєкту є важливим чинником набуття продуктивності команд.
3. Швидке вдосконалення проєктного фреймворку. В ІТ-проєктах важливим є вміння швидко і якісно впровадити зміни. Цей процес вимагає повної залученості імплементаційної групи, що не завжди просто з погляду робочого і часового навантаження.

Висновки

Запропонований фреймворк є відкритою для вдосконалень практично апробованою моделлю. Для вдосконалення підходу пропоную керуватися принципами:

1. Забезпечення комплексної управлінської візії.
2. Критичного аналізу ланцюжка каскаду наслідків реалізації змін.
3. Дотримання універсальності у виборі методичних інструментів роботи ІТ-команд.
4. Формування альтернативних поглядів на імплементацію фреймворку конкретного ІТ-проєкту.

Серед перспективних питань дослідження щодо теми створення універсального фреймворку роботи ІТ проєкту, для колег-практиків можу виділити наступні:

1. Дослідження застосування цього підходу в різних доменних експертизах. Створення статистики та визначення особливостей застосування.
2. Формування та опис широкої бази знань і досвіду рольової участі ІТ-фахівців у впровадженні проєктного фреймворку.
3. Визначення подальших перспективних компонентів структури фреймворку.

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

Відео із серії відкритих ЕРАМ-вебінарів із кросфункційної взаємодії/поєднання функцій РМ/ВА:

• PM/BA interaction: shadow and light of reality | BA Webinar V.1
• PM/BA interaction: in the way of onboard IT project | BA Webinar V.2
• PM/BA Interaction: efficient delivery process formation | BA Webinar V.3
• PM/BA interaction: in the Development Teamwork Process Setup | BA Webinar V.4

Щоби не пропустити нові статті Дмитра Лозовицького — підписуйтеся на нього у телеграм-боті Стрічки DOU.

От редакции: сегодня в украинском ІТ планируются существенные изменения. Они могут произойти уже в скором времени, ведь именно в декабре Минцифра планирует запустить «Дія.City». Поэтому Редакция DOU выступает за то, чтобы об этом проекте узнало как можно больше ІТ-специалистов и каждый мог высказать свое мнение. Тем более, что к проекту пока есть вопросы. Мы уже публиковали интервьюс заместителем министра Минцифры Александром Борняковым, статьюсо взглядом разработчика и вот теперь предлагаем почитать мнение юриста.

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

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

За основу мы берем официальный текст проекта закона «Про стимулювання розвитку цифрової економіки в Україні»№ 4303 с сайта Верховной Рады Украины. Несмотря на некоторое количество альтернативных законопроектов, именно у этого документа самые большие шансы быть вынесенным на первое чтение уже в декабре 2020 с тем, чтобы вступить в силу 1 января 2021.

Что такое «Дія.City»

Согласно ст. 2 вышеупомянутого проекта закона, это особый правовой режим «для стимулювання розвитку цифрової економіки в Україні».

В свою очередь, резидентами «Дія.City» могут стать украинские юрлица «незалежно від її місцезнаходження та місця здійснення господарської діяльності» (ч. 2 ст. 4). Другими словами, не нужно переезжать из вашего офиса в Одессе, Сумах или Ивано-Франковске, чтобы стать резидентом — это виртуальный правовой режим.

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

На что стоит обратить внимание

Хотя и без налогов, этот рамочный закон о «Дія.City» привлекает внимание 5 ключевыми фактами.

1. Полномочия «уполномоченного органа»

Дело в том, что ІТ-компания не просто вступает в «Дія.City» — решение о приеме/исключении принимает специальный уполномоченный орган (п. 1 ч. 4 ст. 12).

Что это за орган? Согласно ст. 12 «Уповноваженим органом є центральний орган виконавчої влади, який забезпечує формування та реалізацію державної політики у сфері розвитку цифрової економіки України».

Если дополнительно взглянуть на ст. 1 Закона «Про центральні органи виконавчої влади», то «Систему центральних органів виконавчої влади складають міністерства України (далі — міністерства) та інші центральні органи виконавчої влади». А я пока не знаю никаких «других» органов, которые формируют госполитику в сфере цифровой экономики, кроме Минцифры. И хотя Минцифры ни разу не упоминается в документе, я далее по тексту буду упоминать именно это министерство.

Что же конкретно имеет право делать Минцифры как уполномоченный контроллер «Дія.City»:

• «Рішення уповноваженого органу про втрату статусу резидента Дія Сіті набуває чинності з дня його прийняття» (ч. 4 ст. 11). А если орган ошибся? Куда можно обратиться за обжалованием/пересмотром решения? В законе об этом ни слова — по факту Минцифры в одном лице объединяет функции регулятора и суд;
• «здійснює контроль за дотриманням резидентами Дія Сіті вимог цього Закону» (ч. 3 ст. 12);
• «встановлює вимоги, порядок та стандарти щодо обов’язкового розкриття інформації резидентами Дія Сіті»;
• «проводить перевірки відповідності резидента Дія Сіті критеріям, вказаним в частині першій статті 6 цього Закону»;
• «роз’яснює порядок застосування чинного законодавства про Дія Сіті»;
• «встановлює наявність ознак порушення резидентами Дія Сіті вимоги про здійснення виключно видів діяльності, встановлених цим Законом»;
• «вимагає від резидента Дія Сіті пояснень та документів для перевірки достовірності інформації, наданої в звіті про відповідність критеріям, або для перевірки будь-якої інформації, документів, наданих резидентом Дія Сіті уповноваженому органу» (п. 2 ч. 4 cт. 12).

Дополнительно, согласно ч. 3 cт. 13, резиденты подают ежегодные отчеты вместе с аудиторским заключением «за результатами перевірки даних бухгалтерського обліку і показників фінансової звітності заявника. Фінансова інформація має бути підготовлена за весь звітний рік».

Мой комментарий: как юристу мне постоянно приходится сталкиваться с органами государственной власти. Несмотря на благие намерения законодателя, любые дополнительные регуляторы IT-индустрии в условиях низких зарплат чиновников приводят к дополнительным коррупционным рискам. К этому особенно чувствительна ІТ-индустрия, которая в Украине развивается скорее как agile, а не благодаря централизованному управлению. Поэтому, если копировать модель Парка высоких технологий из Беларуси — не факт, что получится самый правильный вариант именно для Украины.

2. Организация резидентов «Дія.City»

Согласно ч. 1 ст. 17: «Резидент Дія Сіті вступає в договір приєднання з Організацією резидентів Дія Сіті протягом 30 днів з дня набуття статусу резидента Дія Сіті. Якщо на момент набуття статусу резидента Дія Сіті Організація резидентів Дія Сіті не створена, резидент Дія Сіті зобов’язаний вступити в договір про членство протягом 60 днів з дня її створення».

Что же это такое? «Єдиним об’єднанням резидентів Дія Сіті є організація резидентів Дія Сіті».

Тут не будет лишним процитировать статью 36 Конституции Украины: «Ніхто не може бути примушений до вступу в будь-яке об’єднання громадян чи обмежений у правах за належність чи неналежність до політичних партій або громадських організацій».

А согласно ч. 2 cт. 17: «Резиденти Дія Сіті зобов’язані сплачувати реєстраційний та членські внески до Організації резидентів Дія Сіті у порядку, передбаченому договором про членство».К сожалению, договора о членстве нигде нет и размер этих платежей не понятен. Было бы хорошо это выяснить перед голосованием закона и учесть «скрытые» налоги заранее.

3. Gig Worker

В дополнение к классическим найму в штат согласно КЗоТ и ФОП предлагается новая форма взаимоотношений между работодателем и специалистом — гиг-контракт.

Это абсолютная новелла для европейского законодательства — похожие вещи есть, наверное, в Канаде и частично Великобритании. В чем идея? Это некий микс штата и ФОПа: можно брать сотрудника в штат, но c сохранением гибкости ФОПа.

Привлекают внимание следующие вещи:

• ч. 3 ст. 29 — «Протягом перших трьох місяців строку дії гіг-контракту резидент Дія Сіті має право повідомити гіг-працівника про припинення гіг-контракту в письмовій формі не пізніше ніж за 3 календарні дні до запланованої дати припинення»;
• ч. 5 ст. 29 —«Одночасно з врученням письмової заяви гіг-працівнику про припинення гіг-контракту резидент Дія Сіті має право на власний розсуд відсторонити гіг-працівника від роботи з оплатою не меншою від поденної винагороди гіг-працівника за кожен день такого відсторонення. Наявність підстав, передбачених Кодексом законів про працю України для відсторонення від роботи, не вимагається».

Вот тут интересный момент: как суды отнесутся к подобным формулировкам? Нет же отдельного суда «Дія.City», и решения будут принимать суды общей юрисдикции. А они привыкли к штату согласно КЗоТ 1971 года. С 1999 года судебная практика переварила еще и ФОП на упрощенке. Еще есть так называемые гражданско-правовые договора (оплата условного сантехника, который пришел починить кран). Какое место гиг-контракта в этой системе?

Этот момент усугубляется статьями 30–34 —«робоче місце», «тривалість робочого часу», «тимчасова непрацездатність» гиг-сотрудников — не исключаю, что в судах будет путаница между классическим наймом и гиг-наймом. Что, в свою очередь, может полностью или частично нивелировать концепцию гигов на практике — с переквалификацией в стандартные трудовые договоры со всеми налоговыми и прочими «радостями» — 41,5% суммарно для работодателя и сотрудника. Чего бы мне точно не хотелось, поскольку сама по себе инновация интересная.

4. Срок — 15 лет

Согласно ст. 5 «Правовий режим Дія Сіті встановлюється не менше ніж на п’ятнадцять років з дня набрання чинності цим Законом». А потом?

Также нужно добавить тот факт, что за 30 лет независимости создавалось 12 специальных экономических зон и ни одна (!) из них не доживала до срока своего предназначения. Менялась власть, и другим похожим законом отменялись все предыдущие.

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

5. Турборежим 2.0

Этого нет в законе, но во время официальной презентации в октябре 2020-гобыло озвучено желание законодателя запустить проект уже с 1 января 2021.

Всегда есть две опции: принять документ как есть и дописывать его «на ходу» или сначала «семь раз отмерить». Не думаю, что в условиях пандемии и экономического кризиса нам нужно себе добавлять челленджи. Индустрия и так ежегодно растет на 25% — что изменится, если внимательно дописать этот документ совместно с экспертами и общественностью и запустить проект с 1 июля 2021 года или 1 января 2022 года?

Итоги

Да, инициатива заслуживает внимания и вполне может помочь развитию украинского ІТ. Но сегодня к предложенному проекту закона № 4303 слишком много вопросов.

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

У меня как у юриста слишком много вопросов.

Чтобы не пропустить новые статьи Дмитрия Овчаренко — подпишитесь на него в телеграм-боте Ленты DOU.

Всем привет! Меня зовут Даша, и я Junior QA Engineer. До работы QA-специалистом я занималась контент-менеджментом в другой IT-компании, где познакомилась с несколькими IT-направлениями и поняла, что мне интересно тестирование. Я начала читать профильную литературу, смотреть бесплатные онлайн-уроки, а после занялась подготовкой, чтобы устроиться на должность QA.

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

В этой статье я бы хотела рассказать, как стала Trainee Manual QA Engineer, и развенчать некоторые мифы о входе в профессию. Надеюсь, текст будет полезен для всех, кто решился пройти этот путь.

Иллюстрация Алины Самолюк

Expectations vs Reality

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

Материал, который дают в самом начале курсов, очень легкий. Все начинается с теории: «Что такое тестирование?», «Что такое баг?», «Валидация и верификация?» — этот материал усвоить не сложно. Как и изучить Jira.

Занятия набирают оборот. Треть курса позади (мои курсы длились 4 месяца). И вы подходите к разбору и составлению баг-репортов (необходимо изучить все его поля, знать, что в нем писать, и корректно формулировать проблему).

Затем изучаете тестовую документацию. Следом — техники тест-дизайна и типы тестирования. Дальше мы приступили к GitLab, Linux, веб-технологии, основам нескольких языков программирования, в моем случае это были JS и Java, базам данных.

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

Как выбрать курсы

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

Я выбирала курсы по нескольким критериям:

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

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

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

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

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

Подготовка к собеседованиям

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

1. Не опаздывать, а прийти немного раньше, чтобы успеть привыкнуть к атмосфере и настроиться на интервью.
2. Быть уверенной в своих ответах и не дать себя запутать, умение доказать свою правоту тоже учитывается.
3. Давать четкий ответ, не распыляться. Остальное все спросят.

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

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

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

Самые задаваемые вопросы на собеседовании — теоретические:

• Что такое баг?
• В чем разница между QA и QC?
• Валидация и верификация.
• Типы тестирования.
• Уровни тестирования.

Это спрашивали в 100% случаев. Из своего опыта могу рассказать о некоторых забавных деталях в ходе собеседований. Как-то я отправила резюме в одну компанию и получила отказ на этапе собеседования с HR, а причина была банальной: компания специализировалась на разработке программных продуктов для техники Apple, а я была пользователем Android, вот так вот. Хотя мне казалось, что встреча прошла идеально и я ответила на все вопросы. И тут не нужно расстраиваться, ведь компания ищет людей с похожими ценностями и взглядами.

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

Что необходимо знать, чтобы найти работу

А теперь поподробнее о том, что все-таки нужно знать, чтобы пройти собеседование.

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

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

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

Также не стоит забывать про специфику работы. Моя команда работает с IP-телефонией, поэтому нужно знать сети и протоколы. Я довольно часто в вакансиях встречала требование knowledge the concept of networks, так что разбираться в сетях и протоколах не помешает. Из основного нужно знать модель OSI, TCP/IP и на каких уровнях используются определенные протоколы.

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

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

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

Итог

И в конце хочу добавить немного полезного материала, который поможет в учебе:

1. Основа основ: книга «Тестирование dot com»Романа Савина.
2. Немного о методологияхразработки.
3. Курс по тестированию ПО.
4. Онлайн-курс для понимания основ.
5. По этому курсу я изучала протоколы и сети.
6. Информация о том, как начать свою карьеру.
7. Немного информации о метриках.
8. Сайт о тестировании.
9. Глоссарий ISTQBпоможет разобраться в терминах.
10. ТОП-20 вопросовна собеседованиях.

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

Чтобы не пропустить новые статьи Дарьи Дьяченко — подпишитесь на нее в телеграм-боте Ленты DOU.

Фасилітація — одна з моїх улюблених тем. Я займаюсь нею професійно 7 років, відколи почала навчатись у топфасилітаторів США, Канади, Великобританії, Німеччини та разом з ними працювати в різних проєктах, а згодом фасилітувати міжнародні проєкти та викладати фасилітацію в УКУ. Зараз я співпрацюю з компанією EPAM як Lead Learning and Development Specialist і бачу, як навички фасилітації щодня стають у пригоді ІТ-управлінцям і лідам.

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

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

Зазвичай ми згадуємо про неї, коли:

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

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

Міфи про фасилітацію

1. Фасилітація — нове модне слово

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

2. Фасилітація — це нова назва тренінгу

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

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

3. Фасилітація — це мозковий штурм

Так, мозковий штурм може бути одним з етапів/елементів процесу, але це не тотожні поняття. Наприклад, генерація та збір ідей щодо архітектури проєкту є важливими для групового ухвалення рішення. Та ще важливішим є те, що робити з тими ідеями далі, в якій послідовності й хто буде їх реалізовувати. Просто провести мозковий штурм, записати всі міркування щодо вдосконалення певного сервісу для клієнта на фліпчарті чи онлайн-борді не означає ухвалити рішення. Хоча часто кажуть: «У нас була фасилітаційна сесія, і ми нагенерували ідеї». Але згодом успішно про них забули або не втілювали у життя, бо не було зрозуміло, хто і що має робити. Саме тому фасилітація — це про методи, інструменти, техніки, які підійдуть для розв’язання конкретної задачі, і не завжди мозковий штурм — найкращий варіант.

4. Фасилітація — це багато кольорових стікерів

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

5. Фасилітація — лише для HR

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

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

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

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

Взаємодія фасилітатора і групи

Тепер розглянемо основні принципи роботи фасилітатора з групою.

Фасилітатор — це не експерт, не тренер, не вчитель

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

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

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

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

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

Фасилітатор відповідає за процес і робить його зрозумілим

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

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

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

Фасилітатор — нейтральний

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

Пастка для фасилітатора: оцінювати чи знецінювати ідеї вербально та невербально. Словами «Ця ідея хороша!», «От молодець!» або «Могли б і щось краще запропонувати», «Це вже було!». Мімікою/жестами — одним схвально кивати, а іншим — кривитись чи супитись :)

Що робити? Фокусуйтесь на процесі, на питаннях, які ставите. Пам’ятайте, що результат передусім важливий для групи.

Фасилітатор створює атмосферу залученості

Інколи достатньо трьох попередніх пунктів, щоб була атмосфера залученості. Та все ж є деякі tips and tricks.

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

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

Ще однапастка для фасилітатора: одна чи кілька людей не промовили жодного слова. Хочеться звернутися до них особисто: «А може, Олена хоче щось додати?», «А чому, Андрію, ти мовчиш?».

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

Фасилітатор допомагає командній комунікації

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

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

Що робити? Пам’ятати про свою роль, про нейтральність та про експертність групи. Використовувати всі навички ефективної комунікації, про які так багато написано/сказано: активне слухання, підсумовування, перефразування (без власної інтерпретації), ставлення запитань, паузи, візуалізація тощо.

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

Як буває на практиці

Розглянемо три типові ситуації.

Висновок

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

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

Щоб глибше зануритись в тему, рекомендую книги:

1. Facilitator’s Guide to Participatory Decision-Making, Sam Kaner.
2. The IAF Handbook of Group Facilitation: Best Practices from the Leading Organization in Facilitation, Sandy Schuman.
3. The Skilled Facilitator: Practical Wisdom for Developing Effective Groups, Schwarz, Roger.

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

Про те, як готуватися і що робити після зустрічі, теж якось напишу :)

Щоби не пропустити нові статті Христини Яблонської — підписуйтеся на неї у телеграм-боті Стрічки DOU.

Меня зовут Ольга Мажара, я преподаю «Искусственный интеллект» в КПИ им. Игоря Сикорского и являюсь Senior Java Developer в Intellias.

Я училась в КПИ на теплоэнергетическом факультете по специальности программист. В то далекое время Data Science и ML не были мейнстримом и изучались фрагментарно в рамках других курсов, таких как ИИ или математические методы. Позже, после окончания аспирантуры, преподавала машинное обучение на этой же кафедре. Параллельно работала в Samsung R&D Institute Ukraine. Многие кухонные разговоры на работе были посвящены подходам к изучению Data Science, и мне было интересно сравнивать мнение коллег и студентов.

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

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

Что такое Data Science и Machine Learning

Прежде чем говорить об обучении, начнем с разбора терминологии. Data Science — это общее наименование дисциплин по изучению данных, а Machine Learning — это подразделение Data Science, которое занимается построением умных моделей. Такие модели могут использоваться для предсказания покупки товара пользователем, рекомендаций в соцсетях (рекомендательные системы), распознавания изображений и так далее.

Data Science специалисты занимаются исследованиями. В иностранных компаниях такой должности соответствуют позиции research-инженеров — это в большей мере математики, которые работают с теоретической частью алгоритмов и исследуют разнообразные закономерности. Machine Learning инженеры, в свою очередь, занимаются построением моделей на основе полученных данных. Но такое разделение существует лишь в теории или же только в некоторых странах.

В Украине Data Science и Machine Learning ранее использовались как слова-синонимы, сейчас же эти понятия уже начинают разделять. В наших реалиях вакансии, где необходимо знание Machine Learning, зачастую называются Data Scientist и наоборот. Поэтому, если вы хотите работать с данными, вам следует изучить и то, и другое.

Процесс обучения Data Science и Machine Learning можно разбить на пять блоков:

1. Математика
2. Язык программирования
3. Алгоритмы машинного обучения
4. Deep Learning
5. Отдельные специализации

Рассмотрим каждый из них более детально.

Математика

Для начала давайте разберемся, нужна ли вообще математика в работе с Data Science и Machine Learning. Коротким ответом будет: да, нужна. Безусловно, есть много примеров того, как успешные Data Scientists занимают призовые места на Кaggle-соревнованиях, не имея при этом технического образования. Но даже они согласятся, что знание математики дает значительное преимущество в работе с Data Science.

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

Для успешной работы минимально нужно понимать три раздела математики:

1. Основы линейной алгебры
2. Основы математического анализа (интегрирование, производные и частные производные)
3. Основы теории вероятностей и математическая статистика

Язык программирования

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

Python сам по себе очень простой язык, в нем реализовано множество библиотек для обработки и анализа данных. Популярные ранее R и Matlab сегодня встречается все реже и реже, поэтому, если вы только начинаете осваивать Data Science, сосредоточьтесь на изучении Python.

Базовые алгоритмы машинного обучения

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

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

Теоретическая часть курсов на Coursera бесплатная, а практическая — платная. Но, если у вас нет возможности заплатить за практику, вы можете поискать решения других студентов и специалистов на гитхабе. Кроме того, есть различные специализированные курсы от университетов — Стэнфорда, Гарварда, Мичигана, Университета Дюка и так далее.

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

Deep Learning

Имея базовое понимание принципов машинного обучения и знание Python, можно приступить к изучению Deep Learning. Это один из разделов машинного обучения, в основе которого лежит использование нейронных сетей. Тут я рекомендую к изучению курс Deep Learning Specialization.

Отдельные специализации

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

Сложно ли выучить Data Science

Все зависит от вашего бэкграунда и склада ума. С хорошо развитыми аналитическими способностями и знанием математики ваш путь в Data Science будет довольно простым. Если вы на данный момент учитесь в школе или в университете, старайтесь участвовать в математических олимпиадах. Они помогут сформировать базис аналитического мышления и значительно облегчат освоение профессии в будущем.

Если же решили перейти в Data Science из другой сферы, я бы рекомендовала решать практические задачи на Kaggle. Решайте их самостоятельно, разбирайте решения других людей — все это помогает развивать логику и аналитику. Обратите внимание на блоги различных Data Scientists, YouTube-каналы с разбором и описанием того, как они строили модель, какую логику вкладывали в решение.

Кроме того, в свободном доступе есть много данных, на которых можно практиковаться. Возьмите, к примеру, статистику по заболеваемости COVID-19 и попробуйте найти закономерности (такой конкурс недавно проводили на Kaggle). Вы можете посмотреть на чужие хорошие решения, разобрать логику и постепенно улучшать свои знания алгоритмов. При постоянной практике и наличии аналитического мышления очень скоро вы начнете делать первые успехи в Data Science.

Что почитать

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

И все же советую почитать:

• Hands-on Machine Learning with Scikit-Learn and TensorFlow;
• Deep Learning (Adaptive Computation and Machine Learning series);
• arXiv — ресурс с научными статьями не только по Machine Learning, но и по другим наукам, в том числе фундаментальным.

Чтобы не пропустить новые статьи Ольги Мажары — подпишитесь на нее в телеграм-боте Ленты DOU.

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

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

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

Що таке етикет загалом

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

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

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

Бізнес-етикет

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

Наприклад, команда починає працювати над новою версією аплікації ABC 4.0, в якій потрібно додати певний функціонал. Оскільки роботи багато, то до команди приєднується ще один розробник. Він вирішує написати замовнику, що перед додаванням нового функціоналу потрібно зробити рефакторинг коду і подає це у такій формі: «Before taking any tasks from the backlog, I will clean up the current code. The existing code must be refactored and I know how to do it. Actually, I think that Jonh and Petro poorly performed the code review in previous iterations».

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

• написаний розробником прямо до замовника без попереднього обговорення ситуації з тімлідом або менеджером — цілком ймовірно, що рефакторинг коду доцільний, але на нього потрібно завести окреме завдання і виділити час, а також обговорити в команді, чому код у такому вигляді раніше затверджували;
• оцінює роботу Джона і Петра (poorly performed), а не аналізує ситуацію на конкретному прикладі з коду. Загальне твердження (The existing code must be refactored and I know how to do it) звучить категорично (must, I know), але не підтверджене аргументами;
• порушує субординацію (before taking any tasks from the backlog), бо спеціаліст вирішив обійти беклог і свого безпосереднього менеджера.

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

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

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

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

Онлайн-етикет: електронні листи

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

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

Структура електронного листа

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

Subject line

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

Для коректного розкриття теми важливо звертати увагу на кількість знаків у рядку. Оптимальна кількість: до 30 знаків для мобільної версії і до 70 знаків для вебверсії.

❌ Documents.Одного слова замало.
✅ ABC.2 Validation Documents.Додаємо назву проєкту або фразу, яка конкретизує, про які саме документи йдеться в листі.

❌ Please review ABC 2.0 documents.Формулюємо тему як фразу, а не як речення.
✅ABC 2.0 Documents Review

❌ ABC 2.0 Documentation was Drafted
✅ABC 2.0 Documentation Drafts

❌ Approve document.Звучить як наказ, варто перефразувати й додати деталі про документ.
✅[Action required] Approve Quality Management System Document

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

Address line

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

Reply to all. Відповідайте всім лише за умови, якщо є така домовленість у межах проєкту (і таке буває). Обов’язково відповідайте на лист, який випадково був надісланий на вашу адресу, і повідомляйте відправнику про помилку. Відправник чекатиме відповіді від іншої людини й може пізно зауважити, що адресат був вказаний неправильно.

Хоч ми відсилаємо листа вказаним адресатам, потрібно розуміти, що кожен адресат може переслати лист далі, долучити інших до розмови.

Body

Звертання.Зазвичай ми використовуємо формулу звертання Hello/Hi First Name. Наприклад, Hello Robert. Уникайте звернення на скорочену форму імені, доки немає дозволу від адресата. Сигналом до того, що можна звертатися до людини менш формально, буде підпис, де вказана скорочена форма — Regards, Bob. Відтепер можна не вживати Robert. Недоречно вживати форму, яка особисто вам більше подобається — Hello Bobby. Це дуже фамільярно. Вам не обов’язково пропонувати скорочену форму свого імені, якщо ви її не використовуєте. Наприклад, я ніколи не скорочую Iryna як Ira, оскільки Ira — американське чоловіче ім’я. Нам не обов’язково копіювати культурні норми інших, але варто їх поважати.

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

✅ Several people within our team are having issues installing the new version of ABC. They follow the installation instructions, but still fail to install the application. The new version of ABC is not compatible with our version of XYZ. We are working with the IT department to resolve the issue. Until we can sort this out with them, please find the updates in the G-drive folder. Абзац на кілька речень.

✅ Please let me know if you cannot access the G-drive folder. Абзац на одне речення.

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

I would like to provide an upgrade to a new version of ABC. Here are some highlights of the upgrade.

Known issues and solutions:

1. Summary of issue #1:
   
   • One aspect of solution
   • Another aspect of solution
2. Summary of issue #2:
   
   • One aspect of solution
   • Another aspect of solution

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

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

This is a reminder that ABC_DEV is moving ABC resources to the cloud, and this will change how you access them. From now on, you must log in with User ID and Password(not your email address).

Signature. Дотримуйтесь корпоративного зразка підпису. Якщо ж ви фрилансер, сформуйте свій підпис, який міститиме основну контактну інформацію, за допомогою якої з вами можуть зв’язатися при потребі:

• ім’я і прізвище — саме в такій послідовності ім’я (First Name), прізвище (Last Name). Правильна послідовність допоможе коректно звертатися до вас. Це особливо важливо, якщо ваше прізвище може бути й іменем — Інна Богдан, Іван Борис;
• посада — допускаються загальноприйняті скорочення — Sr Manual QA Engineer, IT Manager;
• країна + місто — ваша локація буде корисною інформацією, якщо компанія має офіси в кількох країнах і/або містах, а також для визначення часової зони;
• контактний телефон — робочий номер, на який ви готові відповідати в разі дзвінків;
• месенджер — для швидкої комунікації. Не варто вказувати акаунт в популярному месенджері, яким всі користуються і в якому ви собі теж завели акаунт, але заблокували там сповіщення і рідко читаєте повідомлення;
• назва компанії або ж посилання на GitLab, LinkedIn для фрилансерів.

Корисні поради

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

Будьте терпеливі. Нагадуйте про те, що хтось має відповісти вам, але не вживайте фразу gentle reminder. Замість цього можна сказати:

Have you had a chance to review the code? (Нагадування, коли справа не термінова, але добре було б дати про себе знати.)

I hope that you will have a chance to review the requirements by the end of this week. (Нагадування, коли відповідь треба дати, бо від неї залежить початок наступного етапу.)

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

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

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

Adding Petro Koval to the conversation. (Усі знають, хто такий Петро, тепер і він буде стежити за розмовою і брати в ній участь.)

Adding Petro Koval, a QA engineer, to the conversation. (Більшість або ніхто не знає, хто такий Петро, але тепер вони мають чітке уявлення про його роль.)

Відповідайте на запрошення. Коли вас запрошують до участі у будь-якій події (зустрічі, дзвінку, лекції тощо), підтвердіть свою присутність або ж відмовтеся. У жодному разі не залишайте такі запрошення без конкретної відповіді (Yes/No/Maybe).

Не тицяйте пальцем в чужі помилки. Виправляти помилки, неточності, одруки потрібно делікатно. Якщо помилка дрібна, її варто пропустити без коментарів і зауважень. Якщо ж одрук — це номер, за яким, наприклад, можна простежити статус завдання в Jira і одна цифра суттєво вплине на розуміння змісту, тоді варто перепитати у приватному повідомленні: «It looks like there is a typo in ABC-012. Did you mean ABC-021?»

Не критикуйте.Вживайте позитивний тон розмови, уникайте формулювань, які справляють негативне враження. Де проходить межа між критикою і конструктивним фідбеком? Фідбек націлений на виконання завдання. Наприклад, пропозиція використати інший метод або інструмент. Критика ж спрямована на людину. Наприклад, «ти не вмієш користуватися інструментом».

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

Уникайте гумору, особливо іронії та сарказму. Розуміння смішного в кожній культурі своє, а тому жарт може бути недоречним або ж образливим. Особливо не варто перекладати жарти. Наприклад, один з колег хотів пожартувати й переклав фразу «Ця фіча не робить погоди» як «This feature does not make the weather». В англійській мові усталений вираз «make heavy weather of something» означає «перебільшувати складність чогось простого».

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

I am sorry for the delay in dry run, but you didn’t provide the build in time.

I am sorry for not attending the meeting, but you sent the invitation 10 minutes before the start, so it was impossible to adjust my schedule.

Як реагувати на неввічливий лист

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

Oksana — QA:

Hi John,
While studying the requirements and preparing the test cases, I discovered that a user may be confused with tabs X and Y. I suggest adding tab Z which will cover requirements 12 and 14, and improve the UI.

John — manager on the customer’s side:

Hi Oksana,
You are not supposed to suggest the requirements, your job is to test. When will the test cases be ready for review?

Hi John,
Please find the test cases attached. If you have any questions or remarks, let me know.

У цьому випадку Оксані буде недоречно вказувати на різкий тон відповіді Джона, пояснювати або виправдовуватися за свою ініціативу, наполягати на своїй пропозиції, а також відповісти порожнім листом, в якому є лише вкладений файл. Все це лише загострить ситуацію. По-перше, ви можете неправильно інтерпретувати текст. І те, що видається нетактовним зауваженням, є насправді іронією. Домалюйте смайлик наприкінці речення і перевірте, чи зміниться його значення. You are not supposed to suggest the requirements, your task is to test. :-)

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

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

Висновок

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

Якщо у вас виникають питання щодо написання електронних листів — обговоримо їх у коментарях.

Щоби не пропустити нові статті Ірини Дробіт — підписуйтеся на неї у телеграм-боті Стрічки DOU.

Мене звати Інна Козак, я Founder of Jungle Courses, CEO в Jungle Consulting, менторка курсів QA та PM.

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

Отже, давно відома практика витрачати ресурси на документування. Сучасний аутсорс-ринок пропонує послуги з документування ІТ-проєктів як must-have для успішного бізнесу. Замовив і забув. Але яка справжня користь документування на проєкті? І чи справді спеціаліст зовні зможе дати таку користь?

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

Проблема документування на продуктових проєктах

Довгий час я працювала над проєктом Х, який був на той час понад 5 років на ринку. Команда невелика, дружня. Проєкт мав певні проблеми в системі управління, замовник втручався в управлінські процеси й час від часу розпоряджався завданнями. Проєкт не стояв на місці, з’являлися нові клієнти, розширювалася команда.

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

Отже, основний недолік — брак інформації. Де її взяти?

1. Збирати інформацію по частинках в кожного учасника команди.
2. Піднімати історію тасків/фіч/багів.
3. Починати описувати роботу проєкту/фіч.
4. Інше.

Проте не все так просто з кількох причин:

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

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

А що в аутсорсі

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

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

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

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

Вихід: налагоджена комунікація та документування від А до Я.

Що таке документація на проєкті. Яка вона буває

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

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

Усю документацію можна розділити на дві основні категорії:

1. Product documentation
2. Process documentation

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

• System documentation — документи, що описують саму систему та її частини. Це Requirement documents, Design decisions, Architecture descriptions, Program Source code, Testing documents.
• User documentation — це інструкції, які підготовлені переважно для кінцевих користувачів продукту та команди підтримки. Це Tutorials, User guides, Troubleshooting manuals, Installation, Reference manuals.

Process documentationописують процес. Можуть бути Standards, Project plans, Test schedules, Reports, Meeting notes тощо.

Чим документи відрізняються від проєкту до проєкту

Усе починається з вимог Product requirement document, однак бувають винятки. Тут можна практикувати, хто як вміє. Головне — описати функціональні вимоги. Вони можуть містити Business rules, User stories, Use cases тощо. Хорошою практикою є опис таких основних розділів:

1. Roles and responsibilities.
2. Team goals and business objective.
3. Background and strategic fit.
4. Assumptions.
5. User stories.
6. Acceptance criteria.
7. User interaction and design.
8. Questions.
9. Not doing.

На деяких проєктах відбувається писанина заради писанини. Інші — взагалі не витрачають ресурси на такі детальні розділи. Це й не дивно: погляньмо на два останні розділи Questions та Not doing — як взагалі можливо описати всі питання та фічі, які команда не буде розробляти?

Оскільки команда розв’язує проблеми під час реалізації проєкту X, у неї неминуче виникає багато питань. Ми почали таку практику: записували всі ці запитання та моніторили їх. Здавалося б, це нереально, але нам хотілося мати такі детальні звіти для відстежування будь-якої незрозумілої чи конфліктної ситуації. За якийсь час ми отримали результат. Але кожного разу, стикнувшись з проблемою, можна було «полистати» попередні обговорення. Зазвичай 80% вже мали рішення та були задокументовані кілька місяців тому. Так, про них просто забули чи не звернули на них уваги. А коли настала черга конкретного розгляду питання чи навіть розробки — виявилося, у команди вже є рішення!

User experience designпочинається на стадії вимог і проходить усі стадії розробки, охоплюючи етапи тестування та вихід в production. Процес проєктування UX містить User personas, User scenario, Scenario map, User story map, UX style guide, Site maps, Wireframes, Mock-ups, Prototypes, User flow schemes, Usability testing reports.

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

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

З іншого боку, важко, наприклад, розробляти продукт без задокументованих Architecture & Design Principles. Якщо планували структурувати рішення за допомогою архітектури мікросервісів, то варто описати Solution details, майбутні модулі та компоненти тощо.

Quality assurance documentation. Серед найпопулярніших: Quality management plan, Test strategy, Test plan, Test case specifications, Test checklists. Якщо на вашому проєкті немає тестувальників, то й документації точно не буде. Якщо відділ тестувальників невеликий, вони зазвичай обмежуються тест-кейсами та чек-листами.

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

User documentation. Категорії User documentation також можуть розрізнятися між собою. Їх структурують відповідно до різних завдань користувача та різних рівнів досвіду. Це можуть бути end-users, support, system administrators.

Документація для кінцевих користувачів має якомога стисліше пояснити, як програмне забезпечення може допомогти вирішити їхні проблеми. Деякі частини User documentation замінюються на Onboard training. Але для складних систем необхідні User guides, Video tutorials, Wiki pages, FAQs, Embedded assistance, Support portals, etc.

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

У документах для команд підтримки зазвичай використовують Functional description, що описує функціональні можливості системи, та System admin guide, що пояснює різні типи поведінки системи в різних середовищах та інших системах, вказівки щодо вирішення різних ситуацій тощо.

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

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

Скільки коштує документування

Скільки коштує година роботи розробника/тестувальника над документацією? Ймовірно, стільки ж, як година розробки чи тестування. Є варіант попросити допомоги спеціального Technical Writer, який може бути як частиною команди, так і залучатися зовні.

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

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

Порахуємо загальну суму. Ви платите, наприклад, $100 на годину за 8–10 осіб,які можуть не знати всіх потрібних проєкту нюансів. Або віддаєте ті ж $100 на годину за роботу 4–5 людей,що досконало розуміють процеси. Здавалося б, більше — краще! Але ні, результат визначає не кількість людей, а такі фактори:

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

Висновок один: процес створення документації такий само ресурсно-витратний, як розробка чи тестування.

Хто крайній

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

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

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

Наприклад, на проєкті X настав час, коли необхідно документувати вже наявні рішення. Менеджер делегує це зовнішньому Technical Writer. Практика ця, прямо кажучи, нічого не дала. Writer гарно знав англійську мову і кілька разів на тиждень приходив в офіс, щоб розпитати про якісь деталі проєкту. За кілька місяців роботи ми отримали User guide, який далеко не все покривав. Потім його дописувала QA-команда. А з Functional documentation у Technical Writer взагалі не склалося.

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

Роль QA-інженера у поліпшенні продукту через документи

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

Що повинен робити QA Engineer у щоденному робочому процесі:

• обговорювати ризики;
• підтверджувати строки;
• стежити за ранніми результатами демоверсії;
• знаходити проблеми та дефекти;
• допомагати з тестовими даними (для розробників).

Що має робити інженер із забезпечення якості на етапі планування:

• обговорювати питання і ризики;
• роз’яснювати Use cases;
• визначати зовнішні інтеграції;
• планувати тести для User stories;
• планувати релізи з термінами виконання;
• попередньо розглядати можливі проблеми/дефекти;
• визначати нефункціональні вимоги.

Що повинен робити QA Engineer на етапі релізу:

• тестування User stories, щоб передбачити реальні проблеми якнайшвидше та уникнути повторної роботи;
• скоротити ручну роботу для тестування/швидкого тестування.

Що має зробити інженер із забезпечення якості після закінчення релізу/виходу в production:

• розподілити регресійне тестування;
• проаналізувати, як можна скоротити час;
• синхронізуватися з автоматизованим тестуванням;
• спілкуватися, щоб розв’язувати проблеми якнайшвидше (soft skills)

До чого тут документація? Загалом кожний вищенаведений пункт можна задокументувати. І це стосується не тільки тестової документації. QA-інженер як найближчий «родич» end-users бере участь у всіх процесах. Наприклад, обговорили ризики — записали в Requirement specification, а згодом у Test plan; роз’яснили Use cases — описали Test Cases document, внесли правки в сам Use case document; спланували тести на User stories — внесли правки в документ User stories; вийшли в production — уточнили User guide, Wiki, Tutorials...

Очевидно, що робота тестувальника — це не тільки тестування, а й хороша документація.

Переписати проєкт чи розібратися через документи

Як часто трапляються ситуації, коли потрібно переписати проєкт? Може, не часто. Та в мене були такі ситуації.

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

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

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

Що я пропоную (замість висновку)

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

Командна робота передбачена у всьому: від планування до кінцевих user guides. QA-інженер має колосальний вплив на процес розробки технічної документації. Команда тестування — найближча до кінцевого користувача. Ні замовник, ні менеджери не можуть так сильно зрозуміти «біль» та «радість» від користування продуктом, який розробляє ваша команда. Тому тестувальникам не завадить мати більше контролю над документацією.

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

Щоби не пропустити нові статті Інни Козак — підписуйтеся на неї у телеграм-боті Стрічки DOU.