Я практически Маугли — будучи вполне себе обычным экономистом по крови диплому, я попала в мир IT и выросла в стае программистов. Стать ими не получилось, были другие задачи: тестирование и администрирование в телекоме, аналитика, продуктовая аналитика и проекты, теперь вот контент и всё вокруг него. В мире программистов я вращаюсь ровно 10 лет и он дал мне гораздо больше, чем три высших образования. Знаете, у них есть чему поучиться.
Мыслить системно и планировать
Внутри каждого процесса в нашей жизни есть этапы, связи, причина и следствие, задачи, ради которых этот процесс запущен или исполняется. Часто люди не задумываются о том, как оптимизировать процессы в работе и обычной жизни, поэтому могут случаться те самые глупые ошибки и оплошности. Достаточно немного подумать, структурировать предстоящее важное дело перед началом и риск провала снижается. Перед тем, как приступить к чему-то серьёзному, важному (или даже страшному для вас!) набросайте в голове, в блокноте, в заметках план:
цели и задачи — чего вы хотите достигнуть в конце;
ресурсы: время, силы, чужая помощь, деньги, да хоть настроение;
преимущества: что вы можете сделать сразу и очень хорошо;
риски: что может пойти не так и почему;
окружение: как процесс повлияет на окружающих и как окружающая реальность повлияет на вас.
На первый взгляд это кажется сложным, но по сути такая «проектная», «архитектурная» работа в жизни очень быстро становится привычкой, доводится до автоматизма. Это прекрасный навык, который можно подсмотреть у хороших разработчиков.
Не плодить сущности
Мои первые технические задания для отдела АСУ большой компании выглядели как первый том «Войны и мира» — казалось, что я пишу бесконечно длинное сочинение на тему: «Ну поймите меня, дорогие программисты, и, пожалуйста, сделайте именно так и только так». Одна и та же мысль повторялась по 5-7 раз, в документе описывались все пути использования отчётов и т.д. — то, что для разработчиков уже не имело никакого значения. После нескольких подходов и вежливых просьб просто перечислить поля, пользователей и периодичность отчёта, меня познакомили с понятием бритвы Оккама. Шаг за шагом, ТЗ за ТЗ я училась давать формулировать кратко, ёмко, структурированно. Кстати, получилось не сразу. Зато когда получилось, я полюбила структуры, списки, блоки информации в текстах, видео, инфографике.
Позже, уже в RegionSoft я привыкла к тому, что разработчики не только работают по таким ТЗ, но и в целом мыслят несколько иначе. И это комфортный, простой, приятный тип мышления: всё по полочкам, логично, рационально. И все последующие знания должны непременно раскладываться по этим полочкам, выходит очень ёмко.
Кстати, уже мой личный лайфхак в рамках этого пункта: осваивая большое количество новой информации (на учёбе, на работе, с новым продуктом, в новом проекте), время от времени я беру базовую книгу по теме и прочитываю её. Ничего нового там нет, знакомый материал читается максимально быстро (можно даже по диагонали), но вал новых знаний очень быстро структурируется и в голове восстанавливается порядок.
Быть внимательным к мелочам
На этот навык кроме всего прочего повлияла работа инженером по тестированию в R&D департаменте. Меня неоднократно поражала незначительность мелочей, которые могли привести к проблемам на продакшене и критическим багам. Но это были мелочи только на первый взгляд — на самом деле, каждая из них демонстрировала, насколько профессиональна команда и насколько быстро она готова проанализировать код и найти причины проблемы.
Внимание к мелочам помогает предотвратить рабочие и бытовые проблемы, своевременное реагирование гарантирует положительный исход. Как определить эти самые мелочи?
Спланируйте предстоящее дело.
Абстрагируйтесь от крупных разделов и фактов внутри события, выделите мелочи.
Оцените, насколько важен каждый из выделенных пунктов, на что он может повлиять.
Всё, что оказалось самым важным в списке и есть те самые мелочи, которые могут вылезти в самый неподходящий момент. Не забывайте о них в процессе работы (ну или любого важного и сложного процесса).
И главное, помните: внимание к деталям и человеческая мелочность и паранойя — вообще разные вещи. Избегайте перегибов.
Управлять временем
Вот тут учиться, учиться и ещё раз учиться. Программисты накануне релиза — настоящие собранные и сосредоточенные самураи (не буду идеализировать, в остальные периоды случается по-разному). Они планируют время до минуты, действуют по шагам, отключаются от любых форм прокрастинации и развлечений на работе. Это эффективные периоды активной работы, которые впечатляют продуктивностью и результатом.
Мне удалось научиться планировать рабочее время и рабочие проекты, но пока это за пределами пресловутого work-life баланса и касается только деловой сферы. В остальном — провал. Но есть ряд хинтов, которые помогают преодолевать проблемы со временем.
Переехать жить на Венеру, там сутки равны 243 земным с хвостиком.Не спать. Пробовала — отстой.Ставить дедлайны: основной и промежуточные. Когда есть точка финиша и вы о ней знаете, задачи решаются быстрее и сосредоточеннее. Это же работает и для целей на длинной дистанции (пройти обучение, похудеть, поправить здоровье, купить что-то крупное и т.д.). Причём сроки должны быть конкретным и в конце каждого интервала предполагать результат (кажется, я изобрела спринты).
Чередовать режим работы и отдыха. Кому-то подходит техника помодорро, мне она не зашла по длине интервала и частоте отдыха. Но переключение внимания и передышки строго обязательны — так вы будете работать неожиданно быстрее.
Приоритизировать задачи и цели (как это происходит в бэклоге) и распределять силы и время.
Не корить себя за просрочку и срыв сроков, а разбираться в причинах и устранять препятствия (если во время работы на соседнем экране крутится любимый сериал или шоу, времени на рабочую задачу уходит больше, а вот фоновая музыка способна очень круто изменить темп работы).
Спать. Сонный организм — тормоз.
До IT я работала в сфере высшего образования, отвечала в том числе за организацию рабочего дня руководителя и, к моему огромному удивлению, никто никуда не спешил — то ли не так много задач, то ли деньги государственные, то ли деньги маленькие, а может и всё вместе, но никаких дедлайнов не было, можно было перенести и сдвинуть очень многое. IT — это территория сжатого времени и не особо ограниченной по нагрузке работы, без планирования дел и управления временем крутым специалистом стать, увы, не получится.
Работать интервалами
Практически у всех, кто читает эту статью, работа делится на рутинную, срочную-важную и проектную (например, вы отвечаете за поддержку отчётов в какой-нибудь АСУ, вам нужно срочно-важно спроектировать кастомные отчёты клиентов и вы берёте на себя большой проект создания пользовательской документации одного из ваших продуктов, потому что знаете его лучше всех вместе взятых). Это тот случай, когда нужно взболтать, но не смешивать: каждый из нас знает, в какое время внутри месяца какая нагрузка, может предсказать проектную работу и должен быть готовым к форс-мажорному труду.
Важно научиться работать интервалами: выполнять рутинную работу, отдавать выделенное время под проект и держать в уме интервал для экстренной работы. Это хороший паттерн. Плохой паттерн — это хаотично по мере желания переключаться между задачами, накапливать рутину, чтобы отвязаться одним «хопом», заниматься больше интересным, чем нужным. При таком раскладе рано или поздно случится факап в виде ошибок, багов и даже невыполненных задач, — хотя бы потому что быстро «подрезая» все хвосты, можно не заметить чего-то нового и важного в задаче, что повлечёт кучу других проблем.
Искать закономерности и зависимости
Несколько лет назад у меня перемкнуло мой «командировочный, разъездной» ноутбук. Он начал глючить со страшной силой: и тачпад, и клавиатура. Первый мастер поковырял его, всё заработало, но буквально спустя поездку снова те же проблемы! Отдала опытному сисадмину, который работает с довольно сложной и специфической аппаратурой. Он пояснил, что был пролив клавиатуры — попала влага. Я убеждала его, что пользуюсь девайсом одна и точно ничего не лила. После 10 минут разговора выяснили, откуда вода: в командировках времени мало и я всегда садилась ночами за ноут после душа с мокрыми длинными волосами, чтобы обсыхать и подбивать итоги дня. Микрокапли, пар, влага постепенно делали своё дело. Для меня это стало внезапной зависимостью, но факт остаётся фактом. И я не раз замечала, как айтишники находят интересные зависимости для своего ПО или реализации IT-инфраструктуры.
Помните абзац про мелочи? Так вот, важно не только их найти — важно понять, как отдельные элементы процесса и среды влияют друг на друга, предусмотреть самые неожиданные риски. Если научиться связывать события и факты, смотреть на вещи многогранно и в ретроспективе, всё становится проще: и работа, и общение с людьми, и даже самый банальный быт. Поэтому я всегда стараюсь задавать себе два вопроса: «Откуда у этого ноги растут» и «Что это всем даст в ближайшем будущем». Ответ на них не просто облегчает решение задач, но и, кроме шуток, делает жизнь социальнее: ты понимаешь природу вещей, поведения, поступков.
Кстати, о социальности. Далеко не все программисты — интроверты и злобные маги. Сегодня коммуникации и soft skills играют в их профессии важную роль: обсудить с заказчиком, понять его, презентовать, пообщаться с коллегами, обучить коллег, пройти обучение и т.д. Кодить в своём мирке не получается даже на удалёнке, если вы не инди-разработчик (и то придётся выйти в люди). Поэтому навыкам презентации своих трудов, обучения юзеров и терпеливого общения с клиентами, заказчиками и коллегами у программистов, разработчиков и архитекторов ПО вполне можно поучиться.
Работать молча
Работая в вузе и в маркетинге в начале своей карьеры, к концу рабочего дня я уставала на 300% при довольно умеренной нагрузке (а иногда и откровенно халявных периодах). Для меня это было загадкой и я списывала всё на нервы и неопытность. Так было года полтора — до одной из зим, когда грипп свалил почти весь отдел. Мы с коллегой-логистом сидели вдвоём в огромном кабинете и… работа делалась быстро, было полное ощущение продуктивности и осязаемого результата. Стало понятно: утомляют постоянные разговоры, шум, чай, кофе и прочие перерывы и отвлекающие звуки, которые невольно вовлекают тебя в бездну общения.
У программистов даже в опенспейсе гораздо тише. Кто любит фон, слушает музыку в наушниках, кто любит полную тишину — выбирает звукоизолирующие амбушюры. Такая обстановка значительно повышает сосредоточенность и позволяет выбирать перерыв тогда, когда это нужно тебе, а не когда нужно ответить что-то про любимые сериалы. Но дело, конечно, ещё и в режиме нагрузки и специфике работы, которую описывает знаменитая картинка:
Работать молча или в под любимую музыку — это наименее напряжный для психики вариант, без рассеивания внимания и ненужной информации. Возможно, часть слухов об интроверсии программистов идёт именно отсюда, но какое значение имеют слухи, если есть чётко выраженный положительный эффект :-)
Относиться к технике и программе как к рабочему инструменту
Работая с СRM-системами (как с RegionSoft CRM, так ранее и с другими, включая старый SAP), я заметила, что один из сложных шагов на пути внедрения — обучение сотрудников. Они воспринимают программу как что-то новое, страшное, неизведанное, хотя до этого уже много лет успешно работали в биллинге, СЭД, Excel и т.д. Поэтому важно начать обучение с разъяснения принципа работы систем: те же поля и ячейки, та же функция «сохранить», только привычные формулы и макросы уже написаны программистами и здорово облегчают труд. Та же история с оргтехникой и гаджетами — принцип работы один, а функции определяются конкретной профессией, которой пользователь владеет.
И тогда же (как и сейчас) я заметила, что каким бы прошаренным ни был обучающий эксперт, никто проще, понятнее и глубже не расскажет про работу программы, чем сам разработчик, который знает ПО изнутри. Я не призываю всех идти учиться программированию, но понимание того как устроен софт, здорово облегчает освоение абсолютно любой программы, а также разрушает мифы: так, пользователю уже не кажется, что программу можно сломать, потерять, нечаянно стереть и т.д. Для себя я выбрала получить дополнительное образование разработчика, но в целом достаточно курса, серии лекций или хорошей книги. По мне так, сойдёт любая базовая программа онлайн-школы по разработке — как раз программистом не станете, но на вещи посмотрите по-другому.
Гуглить
Не то чтобы я не умела пользоваться поиском или шаблонами запросов :-) Дело в другом — как ты относишься к найденной информации. Хороший разработчик не потянет к себе в проект чужой код копипастом, не подключит библиотеку, не разобравшись в ней, не остановится на первом же найденном варианте решения. Это же помогает в неайтишной работе:
обращаться к нескольким источниками информации, проверять достоверность сведений;
не брезговать форумами и сервисами ответов, там много профессионалов в любой сфере;
на английском искать в Google, на русском — в Яндекс, сочетать поисковики;
пользоваться англоязычными источниками наравне с источниками на родном языке — благо, вы можете себе это позволить даже не зная языка, автоматический перевод вполне сносный.
Но за «гуглить», конечно, скрывается многое: и умение быстро обучаться и перестраивать на новый стек, и работа с книгами и документацией, и многое другое.
Наверное, это наиболее значимые для меня привычки, но у программистов можно научиться много чему: перфекционизму, умению безжалостно и хладнокровно работать над своей же работой (рефакторинг), предусматривать проблемы (автотесты), быть готовым отвечать за свой софт (обучение и поддержка), терпению (здесь могла быть шутка про компиляцию) и т.д.
И знаете что, нас таких много — кто вдохновился, покорился разуму, положил диплом на полку и шагнул в IT-сферу, чтобы стать одной крови с этим необычным сообществом. Поэтому мы сегодня вместе с вами отмечаем день программиста и знаем, что нужно пожелать: меньше багов на проде и чужого легаси, успешных мержей, адекватных ТЗ, вменяемых задач, чистого кода, спокойных релизов, вечеров пятницы без критикалов, нужных библиотек под рукой и хороших коллег. Кто, если не вы, преобразует этот мир?
