Почему новички время от времени делают «не то»? Почему они не понимают старших инженеров? Всегда ли это происходит из-за отсутствия опыта? И почему время от времени, за разговорами на кухне те же новички называют своих лидов «м*дками»?
Заранее извиняюсь за англицизмы, встречающиеся в статье, но, как мне кажется, без них некоторые предложения выглядели бы довольно косноязычно.
Начнем издалека. Когда я еще учился в школе, у меня было увлечение – игры. А именно Warcrtaft III. И я постоянно играл, играл, играл в нее. Сначала дело ограничивалось играми с ботами, затем, в прекрасном 2003’ем у меня появился интернет и понеслись игры с живыми людьми.
Свою первую игру я проиграл – от нервов и мысли, что я могу проиграть, у меня тряслись руки и мерзли кончики пальцев, а где-то к середине игры на спине выступил холодный пот. Ясное дело, что с таким настроем первую игру я проиграл. Я проигрывал раз, затем другой, а за ним и третий. Это продолжалось довольно долгое время, пока один из моих друзей не посоветовал мне начать смотреть записи игр других, профессиональных игроков.
У меня хватило ума послушаться его и начать наблюдать за профессионалами. После просмотра записей, первые несколько недель я пытался повторить стратегии, которые они применяли для игры. Раз за разом у меня начало получаться побеждать, но эти победы давались как-то совсем тяжело, вымученно и после трех-четырех игр я чувствовал полное истощение организма. В тот момент в голову начала закрадываться мысль что я делаю что-то не так.
Спустя еще пару месяцев, пару сотен игр и пару сотен просмотренных записей, во время просмотра очередного повтора игры у меня в голове наконец появилась мысль, которая должна была возникнуть сразу: профессиональные игроки не нервничали.
Они знали, что делать в каждый последующий момент времени, они знали, как реагировать на каждое движение врага. Они могли сбиваться с ритма, что-то могло пойти не так, что они планировали, что-то они могли делать не совсем правильно – но одно оставалось неизменным: они не нервничали. Их организм работал как хорошо отлаженная и настроенная машина. И в этот момент в моей голове выстрелила вторая очевидная мысль: Нервы добавляют ошибки.
Эти очевидные, и известные всем истины в тот момент стали для меня откровением. Да, я не раз слышал эти мысли от других людей, но не придавал им особого значения (мол говорят и говорят, у меня своя жизнь) пока не ощутил последствия на собственном опыте. В тот момент я решил больше не нервничать и не торопиться. У меня правда не особо получалось, но я прилежно старался. Показатели побед при тех же стратегия игры заметно пошли вверх. Вместо трех игр я стал в состоянии играть до десяти матчей в день.
Возвращаясь непосредственно к статье и новичкам, молодым специалистам. Два основных правила, которые практически никто из них не соблюдает:
1. Не торопиться
2. Не нервничать
По поводу первого пункта мы опять немного отвлечемся и я расскажу притчевую историю о разговоре с лидом еще когда я только начинал свою карьеру.
Опять начну издалека, но потом вернусь к сути повествования, обещаю.
Гарри Каспарова, чемпиона мира по шахматам, как-то спросили на сколько ходов вперед он в партии думает, планируя следующий ход. Спрашивающие считали, что тот сообщит некую внушительную цифру, и тогда они поймут, что же делает его победителем. Но сказанное им показало людям, что они неверно воспринимают даже саму суть игры: “Главное в шахматах не то, на сколько ходов вперед ты думаешь, а насколько хорошо ты анализируешь текущую ситуацию”.
Суть этого метода в том, что, не зная объективно всей своей ситуации, люди начинают просчитывать варианты, которые изначально оказываются ошибочными. И поскольку просчитать все не представляется возможным, очередь до правильных ходов так никогда и не доходит. В результате, мы выбираем лучший вариант из худших. Лучший из тех, которые мы пытались так внимательно рассмотреть.
Применяя ту же самую стратегию к жизни, можно понять, как часто мы, вместо того, чтобы объективно оценить происходящее, пытаемся просчитать ходы наперед, и как часто позднее эти ходы оказываются направленными не вперед, а куда-то в сторону.
Ясно осознать настоящую ситуацию, — это значит сделать так, чтобы варианты открыли себя сами. Тот, кто говорит, что не знает, что ему делать дальше, всего-навсего не знает, что происходит с ним сейчас.
Возвращаясь к разговору с лидом: когда я впервые пришел к нему за советом, меня очень удивила одна вещь: на мой вопрос по задаче он спросил еще с десяток уточняющих, затем замолк минуты на три, потом уточнил что-то еще. Я тогда еще подумал: «что он вообще делает, когда задачу решать начнем, ответ же где-то рядом». Помолчав еще, он начал спрашивать вопросы, про которые я просто не подумал, потому что не знал, что на самом деле мне нужно сделать. И только потом, когда он знал все, что его интересовало, он дал мне ответ. В результате такого, как мне показалось «тормозного поведения» в начале, задача была решена за пол часа правильно.
Раз в пару недель я продолжал подходить к нему и спрашивать похожие вопросы – и его поведение оставалось одинаковым: полностью выяснить начальные условия, задать дополнительные вопросы и только потом начать думать.
В какой-то момент нашей совместной работы я спросил у него тоже самое, что когда-то спросили у Каспарова. На что он ответил, что не думает наперед, пока полностью не разберется в текущей ситуации. В его голове не было даже мысли двигаться вперед, пока не понятно, что его окружает. В тот момент у меня в голове выстрелила очередная гениальная мысль: да он же прав!
С тех пор мой список профессионала расширился третьем пунктом: прежде чем начать действовать, выясни, что тебя окружает.
Другими словами, при получении первых знаний о задании, в голове образуется своеобразная «каша». Цель – от этой каши избавиться и превратить ее в строго структурированную модель, когда все находится на своем месте. Каким образом это делать – тема отдельной статьи.
То есть другими словами, чтобы писать хороший код, да и вообще делать любое дело добросовестно, необходимо соблюдать три правила:
1. Не нервничать
2. Не торопится
3. Выяснить, что тебя окружает
Чего еще не хватает всем новичкам, так это умения формулировать мысли правильно. В частности, правильно задавать вопросы. Как часто вы сталкивались с тем, что к вам подходит новичок и спрашивает: «как добавить анимацию для таба полисей?». Вы смотрите на него и понимаете, что из всего его вопроса вы знаете только слово «анимация». Конечно, пример утрированный, но думаю вы понимаете, о чем идет речь.
В голове у все начинающих сидит мысль, что вы все знаете. Нужно как можно раньше развеять этот миф, иначе нечеткие, плохо сформулированные вопросы будут продолжаться.
Теперь рассмотрим проблему, с которой сталкиваются старожилы проекта: некоторые из стариков почему-то не хотят понимать или не понимают, что происходит в головах молодых разработчиков. Они не учат задавать вопросы, они не объясняют простые, по их мнению, вещи. Они не рассказывают, как думать и как строить цепочки размышлений.
В этом их фатальная ошибка – человеку нужно объяснять, как именно сделать, что именно сделать и почему именно так. Некоторым кажется, что новичок дойдет до всего сам, в процессе. Но реальность далеко не всегда так хороша, как им кажется.
Сталкиваясь с проблемой, люди начинают зацикливаться, тратить время на решение того, что можно было рассказать или спросить. Они задают не те вопросы, потому что не умеют формулировать свои мысли правильно. Они совершают не те действия, потому что не знают, чего хотят добиться.
И главная проблема – они интерпретируют малейшее двусмысленное указание лида по-своему!
Что бы не быть голословным, приведу пример, который отнял у нас лишних десять рабочих дней разработки. Лид переслал письмо мидл-инженеру с описанием задания (реальный текст карточки):
1. User login with read access to Invoice view
2. Admin remove access for user to Invoice view
3. User refresh page with Invoice view
4. User still has access to Invoice view
5. User relogin to the system
6. User has not access to Invoice view
Что делает человек, как прилежный мидл-инженер? Он начинает разбираться почему так происходит, пишет уточняющие письма заказчику, узнает детали, какие системы могут быть затронуты, если он исправит поведение в системе, где этот баг воспроизводится. Затем все это обсуждается, детали реализации согласовываются с сеньорами. На все уходит 5 дней. Еще 5 дней на реализацию и тестирование.
Проходит неделя, от продукт овнера приходит гневное письмо с примерным содержанием: «что вы натворили, всех на ковер». Начинаем разбираться, и после нескольких звонков и писем выясняется, что функциональность, которую правил разработчик, на самом деле была Правильной! А тестировщик, который создавал карточку, описанием задания всего лишь имел ввиду «уточнить, правильно ли работает приложение или это баг!».
Почему-то каждый человек считает, что его собственные мысли, такие простые и понятные, каким-то магическим образом окажутся в голове у других. Что все «лишние и ненужные слова» можно опустить, ведь это само собой разумеющиеся истины. И люди начинают сокращать свои предложения, перестают полностью вводить исполнителя в курс дела, что-то остается недосказанным «потому как это само-собой разумеется».
НО!
НО это никогда не работает. Всегда нужно показать и рассказать, а не отмахиваться от проблемы. Переступить мысль «да ладно, они все там поймут, не тупые же» и написать все по пунктам, каждое слово, которое вы имеете ввиду.
И отсюда очень простой и очень важный вывод: никогда не допускайте двусмысленности при формулировке задания.
Подводя итоги, повторюсь: если вам необходимо «вести» новичков, с первых дней расскажите и объясните им, что для дальнейшего развития карьеры инженера-программиста им крайне рекомендуется научиться соблюдать четыре правила:
1. Не нервничать
2. Не торопиться
3. Выяснить, что тебя окружает
4. Не допускать двусмысленных формулировок своих мыслей
Автор: YURY_PETRANKOV
