- Знание ООП и структуры данных;
- опыт разработки на Java для Android.;
- знание Android API, понимание архитектуры Android;
- знание основ HTTP, XML, JSON;
- опыт работы с системами контроля версий Git;
- опыт работы с Android Studio, Gradle;
- опыт работы с SQL базами данных;
- знакомство с принципами Material Design;
Узнали? Конечно, узнали. Это — одно из стандартных резюме программиста.
Лично мне такое резюме напоминает одну песню, а точнее одну строку этой песни: «Жигули! Едет и уже хорошо!».
Еще напоминает рекламу тех же Жигулей, где наличие ABS, датчиков дождя и света и т.д. выдается за конкурентное преимущество. Ну и лозунг знаменитый: «Таким и должен быть автомобиль!».
А программист таким и должен быть? Если хочет быть, как жигули – массовым, дешевым и «как бы и не
Но мы не такие, поэтому будем формировать и формулировать свое конкурентное преимущество – комплект увольнения.
Комплект увольнения – то, что остается с вами, когда вы меняете место работы. Как пел Юрий Шевчук, «Это то, что останется после меня. Это то, что возьму я с собой».
Комплект увольнения условно делится на части:
- решения (готовые или полуфабрикаты);
- опыт;
- решенные задачи;
- достигнутые результаты.
Деление на части, конечно, условное. Иногда непонятно, к чему относится тот или иной элемент комплекта. Некоторые ребята еще включают в комплект копию рабочей базы, но лично я так делать не рекомендую.
Итак, давайте по порядку.
Работайте на будущего работодателя
Такую фразу я говорил на одной из конференций, и она вызвала много разных откликов. Тогда не было времени объяснить ее подробнее, сейчас исправлюсь.
Работать на будущего работодателя – это базовый принцип, на котором основана работа с комплектом увольнения.
На первый взгляд кажется, что я предлагаю обманывать работодателя, заниматься левыми подработками или саботажем.
Это не так. Я предлагаю синергию, полезную и вам, и вашему работодателю, и вашему будущему работодателю.
Рассмотрим на примере.
Вы делаете некое решение, что-нибудь популярное и востребованное – дашборд, который берет данные из корпоративной системы и выводит их в веб, посредством Google Charts или d3.
Текущий работодатель хочет видеть продажи и движение денег. По крайней мере, вам он так сказал.
Ничего сложного. Можно взять запросами данные сформировать из них необходимой размерности массивы, и изготовить статический скрипт на js по примерам, которые заботливо написали разработчики Google Charts или Recharts. Статический скрипт нужно куда-нибудь встроить, хоть на телевизор в кабинете директора, настроить автообновление браузера – и все, можно осчастливить работодателя.
Тут вы вспоминаете, что собирались менять работу. Мало ли, может в другой город собрались переезжать. И думаете – о, а неплохо бы дашборд с собой взять. Тема популярная, прям на собеседовании на смартфоне покажу, это же не 1С, график умеет красиво масштабироваться и переворачиваться.
Перед вами встает вопрос – а что захочет новый работодатель видеть в дашборде? Тоже продажи и деньги? А вдруг это будет розница, и понадобится средний чек? Или это будет дистрибуция, где внедрен ТОС, и захотят смотреть статус буфера? А вдруг это будет система на php, типа битрикса, и тогда все запросы придется переписать.
Ага, думаете вы, нужна возможность настройки и оторванность от конкретной системы. Пусть можно будет делать произвольное количество показателей, которые выведутся на произвольные дашборды.
Уперлись, сделали – красота. Придете на новую работу и сразу произведете вау-эффект.
А вот вы уволились. Передали дела, рассказали новому программисту про дашборд и другие ваши решения, и ушли.
И тут начались изменения на вашей прежней работе. Потребовалось еще 10 цифр в дашборд. Приобрели еще одну компанию, там учет в БП, тоже нужен дашборд, на время автоматизации по правилам холдинга. Начали проект по стратегическим изменениям – тут уж не обойтись без отдельного, большого, красивого дашборда – стратегического монитора.
Все перечисленное легко и быстро реализуется вашим дашбордом, который остался на прежней работе. А вы в это время уже вовсю осчастливливаете нового работодателя тем же дашбордом.
Теперь остановимся, и посчитаем, кто стал счастливее:
- Вы, потому что получили фору и конкурентное преимущество на собеседовании;
- Ваш новый работодатель, т.к. получил либо готовое решение, либо проверенную идею, которую вы быстро воплотили (по памяти);
Теперь внимание: - Ваш старый работодатель, т.к. дашборд отлично работает без вас, решая все новые задачи за короткое время, а значит – за небольшие деньги;
- И, как ни странно, новы программист, который пришел работать после вас на старую работу.
Все новые цифры в дашборде – уже его результаты, хоть и полученные благодаря вам. Его результаты приносят профит ему.
Итого, 4 счастливчика. Если бы вы оставили первый вариант дашборда (с двумя запросами и статическим скриптом), то радовался бы только старый работодатель, да и то недолго. Как только у него начались бы изменения, они на пару с новым программистом, стали бы вас проклинать последними словами. Одно из слов было бы «говнокодер».
Разумеется, вы могли бы еще и опубликовать свой дашборд на Git, тогда число счастливчиков увеличилось бы в разы.
Понятно, что изготовление правильного дашборда займет больше времени, чем неправильного. Но, поверьте моему опыту, разница очень невелика, по сравнению с преимуществами для всех участников.
И вот перед нами чистая синергия. Вместо 1=1 мы получаем 1=4. И все потому, что работая на текущего работодателя, работали на будущего.
И последнее, чтобы совсем развеять сомнения. Неважно, где вы работаете сейчас, где работали раньше и где будете работать. Принципиально вы:
- Или решаете текущие задачи;
- Или решаете будущие задачи.
И текущие, и будущие задачи есть у обоих работодателей – и у текущего, и у будущего. Так вот, сделав правильный дашборд, вы решаете будущие задачи обоих.
Или по-другому: вы решаете будущие задачи вашего текущего работодателя. Задачи, которые перед ним возникнут, когда вы уже будете в другой компании.
Понимаете?
Наверное, это можно назвать «решать задачи прошлого работодателя». Тоже неприятно звучит, как и «решать задачи будущего работодателя». Вся неприятность связана с точкой отсчета – где находитесь вы, а где оба работодателя – слева или справа по оси времени.
Но теперь вы понимаете, что это просто игра слов все портит. Прошлый, текущий, будущий. Придает какие-то эмоциональные, оценочные оттенки.
Если игру слов отбросить, то становится просто и понятно. Вы работаете на будущее.
Решения
Начнем с юридических вопросов. Обычно забирать с собой куски кода, модули, и библиотеки – неправильно. Кусок программы, вроде как, является интеллектуальной собственностью компании, в которой он создан.
Поэтому я рекомендую фокусироваться на идеях и фишках решений, зная которые можно воспроизвести решение в любой момент.
Но, разумеется, если сложилась ситуация, когда решение можно взять целиком без юридических последствий, то грех не воспользоваться.
Дальше все просто. Решая любую задачу, держите в голове вопросы:
- Как часто такие задачи возникают у текущего работодателя?
- Как часто такие задачи будут возникать в будущем у текущего работодателя?
- Насколько часто такая задача возникает у других компаний?
Если видите, что задача повторяется или будет повторяться, то постарайтесь решить ее абстрактно. Так, чтобы ваше решение было полезно и будущему работодателю, и вашему текущему работодателю, когда вы от него уйдете.
Чтобы правильно отвечать на эти вопросы, придется не только программировать. Нужно смотреть, чем занимаются другие – компании, программисты, вендоры. Быть в курсе направлений развития платформ, фреймворков, индустрии в целом.
Есть даже наука такая – тренд-менеджмент, изучение трендов. Вот ей и можно заняться.
Придется следить за динамикой изменений в своей компании. Как часто меняется орг. структура, менеджеры, бухгалтерия и финансисты/экономисты, продукты, рынки и т.д.
Все эти знания помогут повлиять на ваше решение – делать ли какой-то инструмент абстрактным и отторгаемым, или на этот раз достаточно $p.cat.byId(“000002341”).
Я в своей жизни сделал не очень много отторгаемых решений – порядка 50. Поэтому мой комплект увольнения достаточно скудный. Его ценность я понял не так давно, о чем иногда жалею.
Хотя, даже столь скромный багаж мне много раз пригодился. Например, при смене работы.
Работая на своей первой работе, во франче 1С, я делал доработки производственного планирования для УПП, которые потом вошли в типовую конфигурацию. Так что, если у вас 1С УПП, там есть мой говнокод.
Мой следующий работодатель хотел автоматизировать производственное планирование, и именно мои предыдущие работы привлекли его внимание ко мне – он мог просто посмотреть мои решения. Даже ходить никуда не надо – у него тоже было УПП, и там был мой код.
Работая на этом месте, я сделал «Структуру затрат». Это была маленький отчетик, который проверял цепочки затрат в многопередельном производстве на наличие разрывов – неправильной аналитики при выпуске на затраты. Я выложил этот отчет на партнерскую конференцию 1С, и обнаружил жуткий интерес к нему, потому что типового решения задача разузлования затрат не имела.
В результате, за несколько человекодней отчет стала таким, как сейчас, и разошелся тиражом в несколько тысяч копий.
Следующий работодатель одной из главных задач считал разузлование затрат – там исторически сложилась практика анализа себестоимости продаж в разрезе конечных затрат. Когда я пришел на собеседование, они уже знали о «Структуре затрат» — один из франчей показывал им экселевский файл с выгруженным деревом затрат. Осталось только сказать, что структуру затрат сделал я.
На следующей работе круг замкнулся. Компания работала с франчем, с которого я начинал свою карьеру, и они, естественно, спросили у франча про мой опыт и решения. Вспомнилось производственное планирование, заодно и «Структура затрат», и вот я снова легко устраиваюсь на работу. Здесь же я снова сделал произвольное распределение затрат.
Сейчас я вообще на javascript программирую. Но часть решений из 1Сного прошлого настолько хороши, в смысле своей идеи, что я воспроизведу их на javascript, чтобы они работали в решениях на metadata.js. Например, тот же универсальный механизм планирования, только он уже будет не прикладным решением, а платформенным – настраиваемым автоматически пересчитываемым в фоновом режиме регистром накопления.
Осталась ли польза в тех компаниях, откуда я ушел? Безусловно.
Производственное планирование в компании № 2 развилось (не без моего участия) в шикарную систему управления резервами и закупками. Там же остался механизм распределения затрат и расчета плановой себестоимости, который после смены учетной политики был быстро перенастроен и продолжил приносить пользу.
Компания № 3 успешно пользовалась накопительным расчетом структуры затрат до тех пор, пока не была продана.
Компания № 4 использует все решения из моего комплекта увольнения, и даже не думает от них отказываться после моего ухода. Программисты, которые там остались, потихоньку развивают эти решения. Все изменения, происходящие в бизнес-процессах (а их очень много), легко и быстро вносятся в настройку решений.
Разумеется, у вас найдется масса подобных примеров из своей практики, и наверняка поинтереснее, чем у меня. Абстрактные решения – это синергия.
Опыт
С опытом все понятно – его нужно зарабатывать. Главное, на мой взгляд, делать это управляемо и системно. Опыт – это еще лучше, чем решения, потому что нет никаких юридических способов отнять его у вас.
Вашему работодателю и вашему начальнику, в целом, пофиг, как и какой опыт вы накапливаете. Вас могут посадить на одни и те же задачи, не требующие развития квалификации. Конечно, встречаются правильные начальники, которые управляют накоплением опыта, но это бывает редко. Обычно все ограничивается редкой отсылкой на курсы, от которых обычно мало толку.
Поэтому о своем опыте нужно заботиться самому. И главное тут – цели и измеримость. По принципам, изложенным в статье.
Самый полезный опыт – тот, что получен при решении задач. Если вы сделали интеграцию сайта и КИС, то можете считать, что определенный опыт получили. Если вы пользуетесь уже настроенной интеграцией, то получаете опыта намного меньше. Если вы второй раз делаете интеграцию КИС с сайтом, то ваш опыт возрастает. И т.д.
Понимаете? Ключ составной: практическое решение задач + их количество.
Чтобы точно знать, как и какой опыт набирается у меня и моих сотрудников, я взял модель из компьютерных игр.
Есть игры, модель опыта в которых не похожа на реальную жизнь. Например, Fallout, при всем моем уважении и безудержной 20-летней любви к этой серии. Там вы просто копите очки опыта, а потом их тратите на развитие тех качеств, которые сочтете нужными. Это модель, описывающая платное образование. Накопил денег – пошел на курсы, например английского языка или управления проектами. Нам такое не подходит, это для слащавых топ-менеджеров.
Более приближена к жизни модель накопления опыта в Elder Scrolls. Я – старый, поэтому играл в ES 3 Morrowind, его и буду иметь в виду.
Так вот, в морровинде у вас улучшаются те характеристики, которыми вы пользуетесь на практике. Машете мечом – растет способность меча. Колдуете – умение колдовства возрастает. И т.д. Когда я играл, у меня была высокая способность Акробатика – ровно потому, что я однажды застрял в каких-то горах, зелья левитации не было, и я много прыгал, чтобы оттуда выбраться. Прыжки развивают акробатику.
На своей последней работе я завел такую систему. В системе жили задачи, и я к ним приделал таблицу «Компетенции», а заодно – классификатор компетенций. Когда человек решал задачу, я перечислял компетенции, которые было необходимо проявить для ее решения. И ставил степень применения компетенций, в условных процентах. В итоге стала накапливаться статистика и по каждому сотруднику появились диаграммы наподобие тех, что мы видим в профилях некоторых профессиональных сайтов.
Дальше я, считая себя хорошим начальником, стал диверсифицировать компетенции подчиненных. Если вижу, что один набрал много опыта по задачам запросов на alasql, то переставал давать ему такие задачи, а отдавал их тому, у кого мало подобного опыта. Разумеется, без фанатизма – если задача срочная, то ее получал самый опытный.
На конференциях я упоминал, что на такие вот «задачи для повышения опыта» я отводил до 30 % времени сотрудника. Понятно, что компания – это не университет. Нужен баланс между скоростью и опытом, потому что без расширения опыта скорость достигнет потолка и потеряется потенциал.
Когда вы работаете в команде, то диверсификация опыта важна не только с точки зрения взаимозаменяемости. Первостепенное значение имеет наличие собеседников, которые помогут в обсуждении задачи, мозговом штурме, принятии архитектурных и технических решений. Если только один человек в команде сечёт тему, то поговорить ему будет не с кем.
Одно из преимуществ такой системы – возможность ставить цели и встраивать эти цели в систему выбора приоритетов и исполнителей.
Например, ставим такую цель: Пятачок должен набрать 50 условных баллов опыта по интеграци – любым задачам, связанным с запросами, кешированием коротких пакетов данных и т.д. Система по каждой новой задаче автоматически высчитывает, кому ее лучше дать – по разнице между целью и текущим положением. А вы сидите и контролируете, как поставленная вами цель достигается.
Внедрить и применять такую систему можно и в одного, для себя. Разумеется, если у вас есть цель – заработать опыт, в котором вы будете уверены. Плюс такого подхода в том, что вам ни у кого не надо спрашивать разрешения – вы можете вести подсчет своего experience хоть в блокноте, хоть в экселевском файле. Так, наверное, даже лучше, потому что файл всегда будет с вами – можно сделать накопление опыта сквозным, не зависящим от конкретного работодателя.
Решенные задачи
С одной стороны, это такая уловка, чтобы произвести впечатление на HR. С другой стороны, понимание решенных задач поможет вам все время фокусироваться на продуктах, а не на процессе.
Я был ИТ-диретором, поэтому часто ходил на собеседования самых разных людей, не только ИТшников – у нас была система кросс-собеседований.
И я заметил, что HR делят людей на две категории – ориентированных на процесс и ориентированных на результат.
Делят они сначала по резюме, потом при собеседовании, обращая внимание на формулировки. Если формулировка звучит как «автоматизировал продажи», то это – процесс. Если звучит как «создал и запустил автоматизированную систему продаж», то это – результат.
«Процессников» обычно не жалуют. Это не хорошо, не плохо – просто так есть.
Поэтому резюме лучше писать через призму решенных задач, а не процесса их выполнения.
Но, теперь вы понимаете – чтобы написать решенные задачи, нужны решенные задачи. Если быть честными с собой, то все мы знаем, что программисты далеко не всегда решают задачи. Занимаются решением задач – да. Решают – нет. Про то, как задача в процессе вообще забывается, мы уже говорили.
Кстати, неплохой пример того, как задачи не забываются, можно увидеть в портфолио Студии Артемия Лебедева – там в каждом проекте написана задача, которую они решали. Не берусь утверждать, что они прям качественно решают задачи, но сам Лебедев называет это конкурентным преимуществом своей студии.
Кстати, в каждом проекте у них еще написаны сотрудники, которые его делали. Это шикарно – комплект увольнения в свободном доступе навсегда. Достаточно дать ссылку. Понятно, что это специфика веб-разработки, но не все студии и веб-мейкеры пишут фамилии людей, сделавших проект.
Вернемся к нам. Раз мы работаем на будущего работодателя, важно понимать и уметь сформулировать задачу, которую вы решаете. Прям представьте себе – через год, или два, или месяц вам надо будет рассказать, что за задача стояла перед вами, как вы ее решили, и решили ли вообще.
По сути, вам надо стать наблюдателем, журналистом, биографом или менеджером самого себя – выбирайте слово, которое нравится. Одна ваша половина усердно трудится, вторая – наблюдает, запоминает (а лучше — записывает) и готовится решенные вами задачи продавать следующему работодателю. Отмечает фишки, трудности и то, как вы их преодолели, какие технологии освоили по дороге, как внедрили, как сопровождали и устраняли препятствия.
Каждая решенная задача – понятная, сформулированная, и желательно абстрактная – пополняет ваш комплект увольнения.
Достигнутые результаты
Бывает так, что вам не ставят конкретной задачи, а ставят расплывчатую. Например, говорят «повысить производительность системы», а не «снизить фиксации транзакций вдвое». Или говорят «повысить эффективность решения задач программистами», а не «сократить время исполнения заявок на 30%».
Когда в формулировке звучит цифра, это – задача, и с ней надо обращаться так, как написано в предыдущем разделе. Когда цифры нет, вам придется ее измерять, чтобы было что написать в комплекте увольнения.
Например, занялись вы производительностью. Временем записи документов в систему. Я уверен, что у вас все получится – вы снизите время записи документов. Что потом скажете будущему работодателю? «Я снизил время записи документов». Что услышите в ответ? На сколько снизили. Сколько было, сколько стало, сколько провозились.
Чтобы ответить на эти вопросы, достаточно измерять. Еще не приступив к задаче, ставьте систему измерения, максимально объективную, потому что система измерения – часть решения. Вас наверняка спросят «как измеряли?». Ну и приступайте к решению.
Когда достигнете необходимого уровня, запомните цифры, первую и последнюю. А еще лучше – сохраните график изменения цифры во времени, отметив на нем ключевые события – ваши действия по изменению цифры.
Я так делал много раз, и это очень – очень! – помогает. Во-первых, помогает в процессе, потому что вы понимаете, где находитесь и куда идете. Вы можете оценивать свой прогресс и эффективность своих действий. Во-вторых, это полезно текущему работодателю – он получает более качественный и понятный результат. Система измерения, которая сама по себе становится продуктом, будет использоваться и после вашего ухода, а у работодателя будет одна система координат для сквозного анализа одних и тех же показателей.
В-третьих, и главное – это поможет вам на следующей работе. Особенно, если вам удастся выразить свои цифры в системе координат новой компании. А это нетрудно. То же время записи документов – оно же везде в миллисекундах измеряется.
Итого
Вам могло показаться, что комплект увольнения – это своего рода накопительное резюме. С одной, видимой стороны, это действительно так.
Но суть не в том, что вы сможете показать, а в том, что у вас реально есть, в вашем багаже. Это своего рода продукт, результат инвестиций своего времени в каждого работодателя.
Это – синергичное использование проведенного времени.
Можно просто сидеть и получать оклад, или какая там у вас система мотивации. На входе в компанию и выходе из нее, в сухом остатке, вы только постарели. Если удалось скопить немного денег или что-то стоящее купить, то это еще неплохо. Если нет – и денег не накопили, и активы не нарастили, и опыта не набрались, и решений не создали, и задач толковых не решили, и результатов не достигли, то это очень грустно.
Звучит вроде банально, но я видел массу программистов, которые вообще не меняются при переходе с одного места на другое. Сознательно ищут работу, на которой нужно решать знакомые задачи. Понятно, что в краткосрочной перспективе так безопаснее. Но что в долгосрочной перспективе?
Если же работать на будущего работодателя, то ваш багаж, ваша ценность, ваш комплект увольнения постоянно растет. Это правильная инвестиция.
