Хабрахабр

Комплект увольнения

  • Знание ООП и структуры данных;
  • опыт разработки на Java для Android.;
  • знание Android API, понимание архитектуры Android;
  • знание основ HTTP, XML, JSON;
  • опыт работы с системами контроля версий Git;
  • опыт работы с Android Studio, Gradle;
  • опыт работы с SQL базами данных;
  • знакомство с принципами Material Design;

Узнали? Конечно, узнали. Это — одно из стандартных резюме программиста.

Едет и уже хорошо!». Лично мне такое резюме напоминает одну песню, а точнее одну строку этой песни: «Жигули!

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

Если хочет быть, как жигули – массовым, дешевым и «как бы и не машиной программистом», то да. А программист таким и должен быть?

Но мы не такие, поэтому будем формировать и формулировать свое конкурентное преимущество – комплект увольнения.

Как пел Юрий Шевчук, «Это то, что останется после меня. Комплект увольнения – то, что остается с вами, когда вы меняете место работы. Это то, что возьму я с собой».

Комплект увольнения условно делится на части:

  1. решения (готовые или полуфабрикаты);
  2. опыт;
  3. решенные задачи;
  4. достигнутые результаты.

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

Итак, давайте по порядку.

Работайте на будущего работодателя

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

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

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

Я предлагаю синергию, полезную и вам, и вашему работодателю, и вашему будущему работодателю. Это не так.

Рассмотрим на примере.

Вы делаете некое решение, что-нибудь популярное и востребованное – дашборд, который берет данные из корпоративной системы и выводит их в веб, посредством Google Charts или d3.

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

Можно взять запросами данные сформировать из них необходимой размерности массивы, и изготовить статический скрипт на js по примерам, которые заботливо написали разработчики Google Charts или Recharts. Ничего сложного. Статический скрипт нужно куда-нибудь встроить, хоть на телевизор в кабинете директора, настроить автообновление браузера – и все, можно осчастливить работодателя.

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

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

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

Придете на новую работу и сразу произведете вау-эффект. Уперлись, сделали – красота.

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

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

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

Теперь остановимся, и посчитаем, кто стал счастливее:

  1. Вы, потому что получили фору и конкурентное преимущество на собеседовании;
  2. Ваш новый работодатель, т.к. получил либо готовое решение, либо проверенную идею, которую вы быстро воплотили (по памяти);

    Теперь внимание:

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

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

Если бы вы оставили первый вариант дашборда (с двумя запросами и статическим скриптом), то радовался бы только старый работодатель, да и то недолго. Итого, 4 счастливчика. Одно из слов было бы «говнокодер». Как только у него начались бы изменения, они на пару с новым программистом, стали бы вас проклинать последними словами.

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

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

Вместо 1=1 мы получаем 1=4. И вот перед нами чистая синергия. И все потому, что работая на текущего работодателя, работали на будущего.

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

  • Или решаете текущие задачи;
  • Или решаете будущие задачи.

И текущие, и будущие задачи есть у обоих работодателей – и у текущего, и у будущего. Так вот, сделав правильный дашборд, вы решаете будущие задачи обоих.

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

Понимаете?

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

Прошлый, текущий, будущий. Но теперь вы понимаете, что это просто игра слов все портит. Придает какие-то эмоциональные, оценочные оттенки.

Вы работаете на будущее. Если игру слов отбросить, то становится просто и понятно.

Решения

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

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

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

Решая любую задачу, держите в голове вопросы: Дальше все просто.

  • Как часто такие задачи возникают у текущего работодателя?
  • Как часто такие задачи будут возникать в будущем у текущего работодателя?
  • Насколько часто такая задача возникает у других компаний?

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

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

Вот ей и можно заняться. Есть даже наука такая – тренд-менеджмент, изучение трендов.

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

Все эти знания помогут повлиять на ваше решение – делать ли какой-то инструмент абстрактным и отторгаемым, или на этот раз достаточно $p.cat.byId(“000002341”).

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

Например, при смене работы. Хотя, даже столь скромный багаж мне много раз пригодился.

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

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

Это была маленький отчетик, который проверял цепочки затрат в многопередельном производстве на наличие разрывов – неправильной аналитики при выпуске на затраты. Работая на этом месте, я сделал «Структуру затрат». Я выложил этот отчет на партнерскую конференцию 1С, и обнаружил жуткий интерес к нему, потому что типового решения задача разузлования затрат не имела.

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

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

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

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

Безусловно. Осталась ли польза в тех компаниях, откуда я ушел?

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

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

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

Абстрактные решения – это синергия. Разумеется, у вас найдется масса подобных примеров из своей практики, и наверняка поинтереснее, чем у меня.

Опыт

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

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

И главное тут – цели и измеримость. Поэтому о своем опыте нужно заботиться самому. По принципам, изложенным в статье.

Если вы сделали интеграцию сайта и КИС, то можете считать, что определенный опыт получили. Самый полезный опыт – тот, что получен при решении задач. Если вы второй раз делаете интеграцию КИС с сайтом, то ваш опыт возрастает. Если вы пользуетесь уже настроенной интеграцией, то получаете опыта намного меньше. И т.д.

Ключ составной: практическое решение задач + их количество. Понимаете?

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

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

Я – старый, поэтому играл в ES 3 Morrowind, его и буду иметь в виду. Более приближена к жизни модель накопления опыта в Elder Scrolls.

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

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

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

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

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

Одно из преимуществ такой системы – возможность ставить цели и встраивать эти цели в систему выбора приоритетов и исполнителей.

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

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

Решенные задачи

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

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

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

Если формулировка звучит как «автоматизировал продажи», то это – процесс. Делят они сначала по резюме, потом при собеседовании, обращая внимание на формулировки. Если звучит как «создал и запустил автоматизированную систему продаж», то это – результат.

Это не хорошо, не плохо – просто так есть. «Процессников» обычно не жалуют.

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

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

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

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

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

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

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

Достигнутые результаты

Бывает так, что вам не ставят конкретной задачи, а ставят расплывчатую. Например, говорят «повысить производительность системы», а не «снизить фиксации транзакций вдвое». Или говорят «повысить эффективность решения задач программистами», а не «сократить время исполнения заявок на 30%».

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

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

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

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

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

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

Итого

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

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

Это – синергичное использование проведенного времени.

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

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

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть