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

    • Знание ООП и структуры данных;
    • опыт разработки на 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С, и обнаружил жуткий интерес к нему, потому что типового решения задача разузлования затрат не имела.

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

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

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

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

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

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

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

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

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

    Опыт


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

    Итого


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

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

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

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

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

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

    Комментарии 44

      +6
      Стойкая уверенность, что я уже читал на хабре про это дашбордовое счастье для всех.
      Это повтор или развитие прежней статьи, или мне просто кажется?
      На память — идеи высказываются те же, что и в прошлой публикации.
      *оглядывается в поисках повторяющихся черных кошек*
        0
        Все вышесказанное можно заменить простой и известной лет 30-40 фразой в программировании: делая дизайн системы, думайте о ее будущем развитии. Зачем столько буков?
          +3
          Что бы красиво себя продать.
            +6
            Много букв не о правильном дизайне систем, а про то, что даже работая на дядю, можно работать и на свое будущее. Дизайн системы — просто пример.
            +5
            Автору — спасибо за систематизированную подачу того, что собственно каждый разработчик и так знает, но либо откладывает на потом, либо просто игнорирует и плывет по течению.
              +2
              зачастили вы статьями, начали повторяться.
              возьмите передышку.
                +3
                передышка случится естественным образом. Новый Год же.
                +1
                Не совсем понятно, зачем работодателю знать о накопленном багаже бойлерплейта и решений. Больше зарплату назначит? Маловероятно.
                  0
                  Больше зарплату назначит?

                  Нет конечно. С бОльшей вероятностью возьмёт на работу. А если вероятность уже 100%, значит вы просите слишком мало денег. Прибавьте 10 тыс в резюме.

                    +1

                    Что-то шаг мелковат. Да и прибавлять лучше в процентах, скажем процентов 20.

                  +9
                  Пример с дэшбордом красивый, но в нем много «но». Хорошо если программист угадал тренд, а что если нет? Вот он решил, что неплохо бы сделать внешний конфиг для дэшбоарда (а вдруг захотят внешний вид поправить или еще чего), наделал фабрик и прочих паттернов (руководствуясь другими «а что, если»). Ну и уволился. Пришел новый программист, посмотрел на код. Код работает, но лезть в него страшно. И тут понадобилось что-то поменять, т.к. первый разработчик предусмотрел много разных «если», но вот с новым требованием не угадал. В результате, новый программист вынужден разбираться в навороченной архитектуре и тратить лишнее время. А старый программист успешно клонировал этого монстрика на новое место работы.
                  Кроме этого, не нужно забывать, что решения устаревают. Иногда не только технически, но и идеологически (например, был пейджинг, стал бесконечный скролл).
                    +1
                    … наделал фабрик и прочих паттернов ...

                    Это от опыта, думаю, зависит. «Точки роста» не обязательно (и даже, скорее, вредно) делать готовыми к немедленному использованию. Достаточно куски, которые, возможно, понадобится заменять, вынести в какую-нибудь отдельную сущность, чтобы были явно видны ее границы и было четко понятно, что идет туда и что — оттуда. С тем же конфигом: думаете, у вас будет куча способов его хранить и добавится зависимость, например, от профиля пользователя, но это неточно — сделайте, грубо говоря, вместо констант — какой-нибудь класс-болванку и назовите его так, чтобы все вызовы легко нашлись. Пусть выборка данных будет в отдельном методе, нормализация — в отдельном методе и т.д. Когда захочется добавить «фабрик» — простой поиск по тексту исходников легко даст понять, куда ее приткнуть.
                      0
                      сделайте, грубо говоря, вместо констант — какой-нибудь класс-болванку и назовите его так, чтобы все вызовы легко нашлись. Пусть выборка данных будет в отдельном методе, нормализация — в отдельном методе и т.д.

                      Как у вас все просто. Таким же способом можно и реализовать новые требования, когда (и если) они появятся.
                      Это от опыта, думаю, зависит.

                      Разумеется. Периодически вижу как делают люди с опытом (10+ лет), так вот они оочень сильно себя ограничивают в мыслях «а что если» и делают то, что нужно заказчику с небольшим запасом. Хотя, тут много факторов различных могут влиять.
                        0
                        Таким же способом можно и реализовать новые требования, когда (и если) они появятся.


                        Я, в общем-то, говорю почти об этом. Не надо ничего реализовывать наперед. Но я считаю правильным постараться сделать возможное расширение более безболезненным, если это дешево. Да, нужно уметь сделать именно максимально дешево и трезво оценивать возможный выигрыш (в том числе, на фоне варианта ничего заранее не предпринимать), для этого опыт и нужен.
                    +12
                    Надо понимать, что все что вы делаете на работе за деньги работодателя принадлежит работодателю.
                    Поэтому переход со своим дашбордом в другую контору может расцениваться, как кража интелектуальной собственности.
                    Я конечно видел фразу типо восстановил по памяти, но в целом надо очень аккуратно с этим быть.
                    С другой стороны лейтмотив статьи — надо развиваться и это бесспорно.
                      0
                      Надо понимать, что все что вы делаете на работе за деньги работодателя принадлежит работодателю.

                      Не всё. А только то, что прописано в договоре.
                        0
                        а в большинстве договоров компаний, на которых все стараются равняться, прописано именно это — «все произведенное вами в рабочее время и/или на мощностях компании принадлежит компании». утащить в другое место может выйти боком.
                          0
                          Если говорить за РФ.
                          Во-первых, авторское право — неотчуждаемое, конторе может принадлежать эксклюзивное право, по прошествии 3х лет, если не заключено новое соглашение или договор, то все эксклюзивные права — автора.
                          Во вторых, если в договоре прописано, что человек, допустим, админ, а написал программу бух учета, а в договоре не прописано, что его обязанность писать программы, то бух программа и все права — этого самого админа.

                          ГК РФ 1295.
                            +1
                            авторское право остается за автором. однако продукт, в котором воплощены идеи, принадлежит компании. если этот чарт был написан в компании, где человек работал, то и принадлежать он скорее всего будет компании. если бы это было иначе, то насколько легко было бы выпустить новый продукт, конкурент существующего — переманить к себе автора существующего, он придет вместе с codebase-ом — через месяц у вас релиз.
                              0
                              С 3 годами аккуратней. Это 3 года неиспользования. Если сделали дашборд и его сразу или в течение 3 лет после передачи работодателю стали использовать, то исключительных прав вы не приобретаете, если не оговорено явно обратное. Вот если сделали, но посмотрели на него и использовать не стали даже через 3 года, вот тогда права ваши.
                                0
                                Вы все верно написали, но только половину.
                                Вырезка из статьи
                                Если работодатель в течение трех лет со дня, когда служебное произведение было предоставлено в его распоряжение, не начнет использование этого произведения, не передаст исключительное право на него другому лицу или не сообщит автору о сохранении произведения в тайне, исключительное право на служебное произведение возвращается автору.


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

                                Которая сообщает, что если работодатель будет использовать, передавать третьему лицу исключительные права, то автор имеет право на вознаграждение.
                                Соответственно, если вознаграждения не было(по прошествии трех лет), что подразумевает неиспользование или сохранение в тайне произведения. Что с этим происходит — уже написано вами и мной.
                                  0
                                  Обычно вознаграждение выплачивается по факту передачи. Часто типа один рубль или вообще «включено в ЗП». Кроме того право на вознаграждение не означает обязательство автоматической выплаты, вполне могут не выплачивать пока не попросишь (а 3 года не просишь — уже даже через суд потребовать не получится в общем случае)
                                    0
                                    1) Начну с того, авторское право пожизненно
                                    1.1) Пользуешь пожизненно — платишь пожизненно авторское отчисление
                                    2) ЗП и авторские отчисления это две суммы и оно должно быть прописано в договоре. Если в договоре про авторские отчисления вообще ничего нет, это не говорит о его включении в ЗП.
                                      0
                                      Не пожизненно, а исключительные 75 лет после смерти, а личные — вечны. Платишь как договорились, вознаграждение может быть разовым, с право пользоваться вечно. Сумма не обязана быть указана в договоре явно, достаточно (ну или многие юристы верят, что достаточно) указания типа «данная сумма включает в себя авторское вознаграждение»).
                        +3
                        Особенно это «хорошо» работает, когда есть поток текущих задач. Которые этот «чудо-программист» не успевает делать, потому что делает не то, что просят, а «красиво».
                        И все счастливы. И уволились в один день.
                          +1
                          недавно читал о программисте из MSFT, которому дали плохое годовое ревью и поставили на Performance Improvement Plan (если за полгода нет заметного улучшения, следует увольнение). в комментариях сотрудников в качестве одной из самых частых причин, по которым люди попадают в такую ситуацию, приводится «сотрудник делал не то, что говорили, а то, что он сам считал правильным и лучшим».
                            0
                            в комментариях сотрудников в качестве одной из самых частых причин, по которым люди попадают в такую ситуацию, приводится «сотрудник делал не то, что говорили, а то, что он сам считал правильным и лучшим».

                            А у нас почти всегда причина увольнения — «по собственному желанию».
                            Подозреваю, что тут то же самое. Формулировка «сотрудник делал не то, что говорили, а то, что он сам считал правильным и лучшим» звучит не так плохо, как могла бы звучать реальная причина. А то может показаться, что прямо самых перфекционистов-нонконформистов увольняют, а не низкопроизводительных и некомпетентных.
                              0
                              формулировка «сотрудник делал не то, что говорили, а то, что он сам считал правильным и лучшим» дана не сотруднику, а приведена как самая часто встречаемая настоящая причина в комментариях, оставленных другими сотрудниками. кроме того — это сейчас не про увольнение пока что, а про плохие результаты перф-ревью.
                          +4
                          Во всём этом сквозит «программист в компании». Один. Подчиняющийся кому-то из C*O напрямую. Я один раз работал в такой компании, так что я понимаю о чём речь.

                          … Так вот, это болото для программиста. Во-первых «сам реализовал». Бывает так, что человек идёт и пишет хорошее и полезное. Но чаще всего, продукты или даже внутренние сервисы пишет команда. Из нескольких программистов. В условиях «одинокого карманного программиста» нельзя расти. Можно только баловаться в песочнице. Индустриальный код (если мы говорим про карьеру профессионального программиста) пишется командами и требует работы в команде. Работа в команде радикально отличается от работы в одиночку, и научившись программировать, дальше человек начинает учиться «писать в одиночку», что будет делать жизнь в команде очень сложной. И чем больше человек пишет в одиночку, тем это будет серьёзнее.
                            +1
                            >> Во всём этом сквозит «программист в компании». Один. Подчиняющийся кому-то из C*O напрямую. Я один раз работал в такой компании, так что я понимаю о чём речь.

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

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

                            Подписываюсь!
                            По другому это называется «зона комфорта». Но, что бы научиться чему-то новому, нужно обязательно выйти из зоны комфорта. Это касается всего — начиная от ИТ, изучения иностранных языков, и заканчивая коньками и ездой на велосипеде :)
                              0
                              хм. обидно как-то про автомобили и резюме.
                              Может человек просто не привык всю свою историю изливать в резюме. А если по делу позвонить и спросить, то расскажет, что и как делал.
                                +1
                                Резюме часто единственный способ показать себя, чтобы хотя бы позвонили. Я вот серьёзно задумываюсь при следующем цикле смены работы заказать подготовку моего резюме профессионалам, а в идеале и стартовые коммуникации по заинтересовавшим вакансиям, типа подгонки резюме под конкретные требования и обязанности и написание «бьющего в цель» сопроводительного письма. Ещё бы понять где их найти, таких профессионалов
                                0
                                Про «компетенции» круто. Никогда бы не придумал такого. Ведь часто программисты любят играть в комп. игры, а тут и мотивация по типу комп. игр.
                                  0
                                  YAGNI
                                    0
                                    1. Складывается впечатление, что статью писал HR — представитель «предыдущего» работодателя. Объясню почему.
                                    2. Во-первых, IT-специалистов не надо призывать работать на будущего или на текущего работодателя. Работа вообще то от слова «раб», и потому эта рабская психология изначально подходит только для не самодостаточных профессий (для тех, которым нужен офис, начальник, бухгалтерия и прочее). Ввиду глобализации и востребованности IT, вообще не надо внедрять в сознание людей, что они должны на кого то работать, кроме как на самих себя. Т.е. если хотят, могут работать и на кого то, но не надо утверждать это как единственный вариант.
                                    3. В этой связи, утверждение, что бывший работодатель или тем более специалист пришедший тебе на смену должны будут испытывать «вечное счастье» от твоей работы выглядит смехотворно. А с какой собственно стати Вы должны о них думать после смены работы? Пока вы работаете, они удовлетворены, вы удовлеторены (если речь не о случае, когда это Вас увольняют!). А дальше, вам же с ними детей не крестить, о ни же о Вас после ухода не думают.
                                    4. Далее. Когда нас нанимают, мы соглашаемся на совершенно конкретные условия и нам ставят вполне конкретные задачи. Условия работы (т.е. мат. компенсация и соц. пакет) составляют нашу мотивацию к данной конкретной работе, а не к работе вообще на всю оставшуюся жизнь в будущем. Это материальная мотивация к труду. Мы всегда хотим большего, чем может предложить рынок, но принимаем компромисс, так почему работодатель должен мечтать о самом лучшем максимально универсальном результате в плане разработки? (если условия как в российском ООО, то никогда не получите, решения, как в Гугле!). Второе — это собственно работа т.е. задачи по разработке совершенно конкретных решений. Для этого принято сначала делать чёткое ТЗ, по кот. можно отследить, всё ли было сделано, и что и как реализовано (чтобы потом не было повода обзывать экс-сотрудника «говнокодером» и прочее). Но даже более важно, что ничто не происходит в вакууме! Любые разработки всегда упираются в определённый ресурс — временной дедлайн, человеческий ресурс, ограничения мощности железа, требуемую производительность, масштабируемость решения и.т.д. ну и в том числе, никуда не денешься, в нашу мотивацию (за те же деньги), делать «точечное» решение или глобальное универсальное т.е. работать или перерабатывать по-русски говоря. Почему мы должны выходить из зоны комфорта, если нам комфортней в ней оставаться в конкретном случае (т.е. использовать привычные технологии и делать может более узкий, но зато именно тот, что просили функционал)? Не надо забывать, что ценность каждого работодателя в данный момент времени для сотрудника м.б. разной. Не вся работа одинаково полезна и хорошо оплачивается! Возможно программист рассматривает эту работу как временную, возможно он хочет открыть свою контору по разработке или перейти в крупную компанию. Опять же есть вопрос work-life баланса, — что важнее сделать всё идеально на работе или вести в целом полноценную жизнь?! В зависимости от этих целей человек сам себе и выбирает глубину проработки задачи для своего портфолио проектов! Автор же утверждает в статье, что нужно всегда при любых условиях стремиться делать наиболее универсальное, всесторонне масштабируемое и желательно не зависимое от технологии решение. Объяснение одно — это Вам поможет на следующем собеседовании. Ну понятно, что такой подход максимально в интересах вашего текущего работодателя по принципу «сделать из говна конфетку» на все времена. Когда нужен конкретный автоматизированный отчёт и сроку вам 3 дня, делать конструктор отчётов с прикрученной системой аналитики и максимально «кошерным» интерфейсом, это и глупость и «самоубийство» для сотрудника!
                                    5. С чем соглашусь, так это с тем, что построение таких «продвинутых» универсальных решений исключительно благотворно сказывается на твоей профессиональной компетенции и на скорости работы в будущем и даже на общем системном подходе к разработке в вашей голове. Поэтому, если цель — максимальный рост проф. компетенций, то это хороший путь, также, как, когда хочешь серьёзно освоить математику, необходимо после стандартных решать все задачи со звёздочкой! Если хотите проф. роста, то будете «заморачиваться» работой и вне работы по выходным. Но на практике в нашей действительности — это всё благие пожелания, кот. вымощена дорога, сами знаете куда. В мировой IT-индустрии, то что расписал автор — это безусловно best practice к которым стоит стремиться, если Вы работаете на цивилизованного западного работодателя. У нас — это называется «рвать *опу ради Дяди за копьё»!
                                      0
                                      В мировой IT-индустрии, то что расписал автор — это безусловно best practice к которым стоит стремиться, если Вы работаете на цивилизованного западного работодателя. У нас — это называется «рвать *опу ради Дяди за копьё»!
                                      работайте на аутсорсинге и будет вам счастье. Достаточно один раз поработать на цивилизованного работодателя, чтобы понять — на каких работодателей вам стоит искать.
                                        0
                                        2. Какая разница как слово произошло? Сейчас оно имеет вполне определённые значения, в частности добровольное исполнение трудовых обязанностей в обмен на, прежде всего, денежное вознаграждение и перекладывание на работодателя забот об организации труда и различных рисков. Вроде никто не утверждает, что каждый должен работать в капиталистическом (хотя бы номинально) обществе. И не надо внедрять в сознание, что работа «на дядю» это что-то плохое, что стремиться нужно к чему-то другому.

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

                                        4. Часто работодатель берёт на работу технического специалиста чтобы тот решал бизнес-задачи техническими методами, а не технические задачи с чётким ТЗ и полным техническим контролем. И работу такого специалиста работодатель проконтролировать может только по одному аспекту: решена или нет бизнес-задача. При этом ему всё равно какие языки, платформы, архитектуры и паттерны использовались. Но он заметит что-то неладное, если оценка сроков/стоимости изменения бизнес-фичи будет равна оценки её разработки с нуля. Ну а в целом посыл статьи, что вообще нужно думать о проработке своего портфолио, если не исключаешь смену работы, а не тупо решать технические задачи.
                                        0
                                        Бывает так, что тебе дают однотипные задачи, и ты ничего не можешь ничего крутого предъявить на следующей работе.
                                        А бывает так, что пилишь для них какую-нибудь интеграцию, тебя увольняют, а твой проект считается теперь их проектом.
                                        Так что всегда следует позаботиться о себе и накопить такой увольнительный пак.
                                          0
                                          Часто есть возможность как раз на однотипных задачах сделать достаточно универсальное решение. Так и появляются фреймворки, библиотеки, кодогенераторы и т. п. Под вопросом может быть интеллектуальная собственность на это решение, но в целом строчка в резюме типа «оптимизировал процессы разработки, разработав универсальный инструмент для решения задач такого-то типа, внедрение которого сократило время решения такой типовой задачи на 1000%» даже с окончанием «после чего был уволен за ненадобностью» :)
                                          0
                                          Довольно плоское изложение инженерной работы, как по мне. Часто бывает что время на гибкое или универсальное решение на порядок (!) отличается от времени на добавление нужного функционала «здесь и сейчас». Плюс практически в каждой нетривиальной системе имеется в наличии определенный объем технических долгов, которые точно не ускоряют разработку гибких универсальных фич. Поэтому и получается что «работа на будущего работодателя» может сильно снизить КПД работы для текущего работодателя, особенно при доминировании операционных задач (когда надо просто вклеить новый график в мониторинг, а не изобретать велосипед для мониторинга)
                                            0
                                            Особенно если нужен, помарочный учет(ЕГАИС), нужен вчера, иначе штрафовать уже начнут :D
                                            0
                                            Как-то очень завуалированно у вас получилось донести ясную мысль: «мое дело — резюме наращивать, и чтобы было о чем на собесах рассказывать, а вы тут занимайтесь своим бизнесом-шмизнесом, у меня в нем доли нет». Сказки про синергию и будущих работодателей тут совершенно излишни, хоть и могут оказаться полезными, когда вы будете объяснять сегодняшнему нанимателю, зачем вы на работе точите свои велосипеды.
                                              +1
                                              вот же:

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

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


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

                                              Причем тут резюме?

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

                                            Самое читаемое