Получить проект в свои руки с самого начала — большая удача. Намного чаще случается, что вы устраиваетесь в новую компанию и вам проект передаёт один из штатных менеджеров. Либо вы увольняетесь и передаёте проект коллеге.
Я решил собрать в одной ментальной карте все аспекты и вопросы, которые нужно учесть при такой передаче. Вот вам pdf:
А вот исходный файл (Minjet Mindmanager).
Вот ещё хороший пост про передачу дел:
1
Нужно ли пиэму программирование — вечная тема для холивара. Выскажу свой взгляд на этот вопрос и расскажу про другие хард скиллы, которые могут понадобиться руководителю проектов в различных организациях (а могут и не понадобиться). Речь пойдёт, конечно, об IT-пиэме.
Сначала нужно выучить терминологию, например, по этой статье.
Современный пиэм должен уметь вести проекты как по гибким, так и по фиксированным методологиям, которые предполагают рисование диаграмм Ганта и их актуализацию на основании реальных данных.
Лучшее решение, которое я видел — плагин BigPicture для Jira. Позволяет брать реальные эпики и таски из джиры и из них делать «колбаски» ганта. Состояние задач в диаграмме будет апдейтиться автоматически. Даём гостевой доступ заказчику и ссылку на эту диаграмму и наступает общее счастье.
Если этот вариант невозможен, придётся использовать Microsoft Project для винды или аналоги для макоси, вроде Merlin Project или Omni Project. Все они устроены примерно одинаково.
Для того, чтобы понимать в речи разработчиков что-то, кроме предлогов, основы программирования знать и понимать нужно. Разберитесь, что такое переменная, цикл, ветвление, массив, класс, подкласс, экземпляр класса, объект, метод, интерфейс. Многое сразу станет понятно.
Также нужно разобраться, что такое гит, коммит, пулл-реквест, мердж-реквест, зачем нужен мердж веток, что такое мастер ветка.
Записываться на курсы разработчиков не нужно, это скорее навредит, чем поможет.
Скорее всего, вам придётся начинать карьеру в маленькой компании, в которой на всех экономят, в том числе, на аналитиках, поэтому выяснять, что же нужно сделать в рамках проекта и оформлять всё это в читабельное ТЗ нужно вам. Пробегите Вигерса, хотя бы по диагонали, станет легче.
Да, в скраме нет ТЗ, там есть стори. Но легче от этого не становится, фичи всё равно, нужно расписывать, если этого не делать, разработчики закодят трешню. А если закодят не трешню, на этапе приёмки заказчик вам скажет, что имел в виду не это и вы ничего не сможете доказать, придётся переделывать.
Суть большинства проектов сводится к тому, что нужно сходить в БД за данными, красиво их отобразить, дать пользователю отредактировать, потом провалидировать и аккуратно сложить обратно. То есть, всё завязано на БД.
Вам нужно понимать, что такое БД, как она устроена. Что такое первичный ключ, внешний ключ, зачем нужны индексы и индексация. Может так сложиться, что вам придётся спроектировать модель данных. То есть, берёте предметную область проекта, выделяете сущности, декомпозируете их на атрибуты, делаете связи, скармливаете программисту, чтобы он из этого сделал БД.
Иногда бывает полезно уметь составить простенький запрос к какой-нибудь таблице с каким-нибудь условием.
Вот, например, код, выгребающий из одной базы подробную статистику трудозатрат по идентификатору доработки:
declare @id nvarchar(1000)
SET @id = 'CAS-191131-B8B3'
SELECT ROUND((SUM([Затраты])* 24), 2) as 'Итоговые затраты'
FROM [STAdministrationResource].[dbo].[vw_DO_TFS]
WHERE Затраты IS NOT NULL
AND [Запрос.Номер CRM] LIKE @id
SELECT Роль, ФИО, Тикет, ROUND((SUM([Затраты])* 24), 2) as 'Затраты'
FROM [STAdministrationResource].[dbo].[vw_DO_TFS]
WHERE Затраты IS NOT NULL
AND [Запрос.Номер CRM] LIKE @id
GROUP BY Роль, ФИО, Тикет
ORDER BY Роль, ФИО, Тикет
GOБолее сложные запросы нужны реже, можно попросить программиста помочь.
Интеграция нужна практически везде, разве если только вы не делаете какой-нибудь калькулятор, да и то, хороший калькулятор должен уметь забирать курсы валют. Вам нужно разобраться, что такое API, зачем оно нужно. Советую сначала изучить SOAP, он интуитивно более понятен (на практике используется в энтерпрайзе для подруживания нескольких систем), потом изучите принципы REST (он используется на современных сайтах и веб-приложениях).
Научитесь читать и редактировать XML и JSON файлы. Если сильно не повезёт, вам могут поручить и проектирование API, у меня такое было раза три за карьеру.
Много очков в глазах работодателя даёт умение пользоваться Postman. Изучите его, он интуитивно понятный.
Разберитесь, как устроена HTML-страница, какие теги за что отвечают. Разберитесь, зачем вообще, нужен CSS. Принципы каскадирования и наследования в рамках соответствующих таблиц.
Потом научитесь пользоваться консолью разработчика, хотя бы в одном браузере. Очень важно уметь посмотреть, какие стили применились к данному элементу страницы и если надо, их подправить. Также нужно уметь пользоваться консолью ошибок, потому что первый вопрос, который вам задаст разработчик в ответ на ваше: «На сайте ошибка», будет: «Что в консоли?».
Во всяких бутстрапах разбираться необязательно.
Скорее всего, в работе вы столкнётесь либо с Битрикс, либо с WordPress. Очень полезный навык — умение разобраться, где в админке поправить данный кусок контента и сделать это, когда это нужно срочно, а контентер уже спит.
Изрядная часть работы пиэма связана с созданием и редактированием разнообразнейших таблиц. Чем лучше вы владеете Excel и гуглотаблицами, тем выше ваша продуктивность и ценность. В Скайэнге вообще, требуют в тестовом на пиэма задание, предполагающее написание макросов, но это единичный случай.
Сюда же входят навыки по работе с матрицей рисков, которую часто исполняют в виде обычной таблицы.
Сюда же входят навыки по работе с реестром заинтересованных лиц и другими проектными таблицами.
Вот хороший телеграм-канал про секреты гуглотаблиц.
Никто не требует от вас виртуозного владения никсовой консолью, но принципы методологии девопс сейчас применяются повсеместно. Надо знать и понимать, зачем и для чего нужны все эти докеры, куберы и кэш балансеры. Вот хорошее руководство.
Очень хороший ролик Дмитрия Ильенкова из PM Club о самых частых ошибках прожектов.
Ранее у меня был пост о проектных ролях. Этот пост — продолжение темы. В нём я хотел бы поговорить подробнее о команде проекта, кто в неё входит и что делает. Состав команды меняется от компании к компании, от проекта к проекту, я постараюсь перечислить максимум специальностей. Писать буду взгляд на каждую должность с позиции менеджера проекта.
Выделенный менеджер продукта (далее продакт) обычно встречается в командах продуктовой разработки. В заказной разработке продакт обычно существует на стороне заказчика (некоторые специалисты считают это плохой практикой, но это данность).
Занимается продакт много чем, но основное его занятие — поставлять проектной команде продуманные, проработанные с продуктовой точки зрения задачи и давать приоритеты для этих задач, объясняя, что первостепенно важно, а что просто желательно.
Часто продакт работает в тесном контакте с дизайнерами, в результате такого сотрудничества вы вместе с продуктовой задачей будете получать и дизайн.
Если вы пиэм, продакт, как правило, не является вашим руководителем, скорее заказчиком.
Аккаунты встречаются напротив, в заказной разработке, где есть много общения с клиентом. Чаще всего аккаунт ведёт несколько проектов.
Занимается тем, что уменьшает количество вашего общения с заказчиком, беря его на себя. Часто берёт на себя оформление различных юридических документов при поддержке юристов. Поддерживает с заказчиком хорошие отношения, часто допродаёт услуги (иногда не посоветовавшись с вами). Если аккаунт технически подкован, ему можно делегировать встречи по статусу проекта, но я бы рекомендовал делать это самостоятельно.
Эйчары бывают как в продуктовой, так и в заказной разработке.
Занимается тем, что облегчает вашу работу с кадрами. Хорошему эйчару можно делегировать изрядную часть процесса найма сотрудников. В идеале можно будет скинуть ему требования к кандидатам и временные слоты, в которые вы и ваши коллеги будут готовы проводить собеседования, он сделает всё остальное.
Также эйчар периодически проводит контроль удовлетворённости сотрудников работой, может дать полезный совет.
В небольших компаниях эйчар совмещает функцию кадровика, в крупных это чаще разные люди. Заключение с сотрудниками договоров и допсоглашений при найме, сопровождение процесса увольнения, документальное оформление повышений и переводов на другую должность, ведение трудовых книжек и многое другое относится сюда.
Иногда технический директор компании, иногда директор айти-департамента, в общем, главный айтишник в организации. В маленькой компании может быть до кучи и тимлидом, в крупной — чистый управленец.
Занимается выработкой айти-стратегии организации и доведением до вас этой стратегии. Будет время от времени поставлять вам технические задачи разной сложности, но обычно высокого приоритета. Например, перевести разработку в другой гит сервис, срочно отредактировать контент, убрав инфу, ставшую незаконной и тому подобные радости. Мой вам совет — никогда не игнорируйте задачи этого человека.
Обычно назначается из самых опытных и коммуникабельных разработчиков. Как правило, сотрудник вашей организации, но может быть вариант с тимлидом на аутсорсе.
При правильно выстроенных процессах и правильно подобранном на эту должность человеке, освобождает вас от необходимости вручную управлять разработчиками. Распределит задачи, исходя из компетенций, ответит на техническое вопросы, разрулит конфликты при мерже веток, вместе с вами проведёт собеседования кандидата в разработчики.
Часто выполняет функции архитектора системы, проводит код ревью. Также ему можно поручить ассессмент разработчиков, только не забудьте предоставить шаблон.
Фронтенд-разработчики встречаются в веб-разработке. В крупных командах есть разделение на верстальщиков и именно фронтенд-разработчиков, но чаще верстает фронтендер.
Если в двух словах, он делает две вещи. Чтобы итоговая страничка выглядела строго так, как в дизайне, причём на всех поддерживаемых разрешениях, включая мобилки. Называется «интеграция вёрстки». И чтобы интерактивные элементы на странице вели себя правильно, анимации воспроизводились, кнопки нажимались и всё такое. Кроме того, подключается к API, созданном бэкендерами, забирает из него данные и красиво отображает на странице. Но если API пока не готово, умеет отображать вместо реальных данных моковые.
Делает он всё это, как правило, на JavaScript. В чистом виде JS используется редко, чаще применяется один из JS-фреймворков, например React, Vue или Angular.
Игра на выпивание для фронтендеров. Игроки по очереди берут английский словарь, открывают на случайной странице, тыкают в случайное слово и гуглят, есть ли JS-фреймворк с этим словом в названии. Если есть, все выпивают.
Неизвестный автор
Встречается везде, где нужен бэкенд. Бэкендеру, в целом, всё равно, как будут использоваться его методы, они одинаково работают как на интерактивном билборде, так и экране умного чайника, в этом плюс профессии.
Неайтишные заказчики часто вообще не понимают, что такое бэкенд и зачем им нужно оплачивать его разработку. На деле же бэкенд-разработчик создаёт модели данных, если нет dba (о нём ниже), то генерит и конфигурирует базу данных, разрабатывает методы API через который клиентское приложение будет с базой общаться и делает ещё десятки всяких полезных активностей.
Хорошие бэкендеры владеют несколькими языками программирования: C++ или C#, PHP, Python и фреймворками, которые сильно облегчают им бэкенд-разработку. В случае, например с PHP, это Laravel или Symphony, для Python популярен Django.
Если нет девопса (о нём ниже), чаще всего вопросами гита и развёртывания тоже занимается один из бэкендеров.
Обитают в компаниях, занимающихся разработкой приложений для смартфонов. Рыночек порешал так, что фактически осталось две платформы — Android и iOS. Соответственно, разработчики делятся на три группы — андроидщики, айосники и специалисты по кроссплатформенной разработке.
Мобильные разработчики в чём-то аналогичны фронтендерам — они отвечают за ту часть приложения, которую видит пользователь. Верстают экраны, поддерживая зоопарк разрешений, подключаются к API и вытаскивают из него данные, красиво отображают. Также эти ребята обычно знают тонкости публикации приложений в сторах.
Айосники обычно пишут либо на Swift (чаще), либо на Objective С (реже). Андроидщики — на Java или более новом Kotlin.Технически подкованные ведроводы, пищущие особо сложные приложения или игры, используют C/C++
У специалистов по кроссплатформе всё сложно.
У вас уже наверняка пошла голова кругом, а понимания что выбрать, так и не появилось. Давайте представим простой список вопросов, который вам поможет:
livetyping.com/ru/blog/na-chem-pisat-krossplatformennye-prilozhenija
Должно хоть как-то работать на любом устройстве? Выбирайте HTML как основу
У вас есть «встроенный» веб-разработчик или вы просто хотите быстро и просто попробовать мобильное приложение в деле? Тут можно рекомендовать Cordova/HTML или PWA;
У вас есть собственная CRM-система и поддерживающий ее C#-разработчик? Берите Xamarin;
Вы «хотите попробовать», но надо сделать всё красиво и модно? Смотрите в сторону React Native или Flutter.
К сожалению, код без багов невозможен, как и баг без кода. Даже если у вас суперразработчики, которые пишут основной поток без багов. Можно придумать простые и логичные сценарии использования приложения, но пользователи, всё равно, будут использовать его так, как ни одному здравомыслящему человеку в голову не придёт.
Секретарша пожаловалась, что у неё тормозит компьютер. Пришёл разбираться и обнаружил, что она несколько лет вела все документы в одном вордовском файле. Когда его размер превысил полгигабайта, комп забастовал.
Неизвестный автор.
Это та часть работы тестировщика, которая на виду и на слуху. Проверить все, даже самые экзотические сценарии и убедиться, что приложение работает на них без ошибок. Но тестеры занимаются не только этим.
Тестировщик обязательно должен входить в микрокоманду с самого старта работы над требованиям, так как его опыт и стиль мышления позволяет провести глубокую рецензию требований и выловить несоответствия на бумажном этапе, сильно сэкономив компании деньги.
Когда-то путь тестировщика считался самым простым способом входа в айти. В 2022 требования к ним сильно выросли, современный тестировщик должен уметь развернуть на своём компе ветку разработчика, постучаться в API при помощи Postman или Swagger, отлично уметь пользоваться консолью разработчика в браузере и не только в Хроме, а вообще во всех, уметь составить запрос к БД и многое, многое другое.
Самые системные и коммуникабельные тестировщики становятся лидами тестирования и начинают относиться уже больше к менеджменту.
Об этой специальности неайтишные заказчики знают ещё меньше, чем о бэкендерах и убедить их оплатить автоматизацию тестирования ещё сложнее.
Если простыми словами, то тестеры-автоматизаторы пишут код, который тестирует код, чтобы его не приходилось тестировать руками.
Всё переплетено в единый моток
Oxxxymiron о монолитной архитектуре
Нитяной комок и не ситцевый платок
Перекати-поле гонит с неба ветерок
Всё переплетено, но не предопределено
Проблема разработки больших приложений, особенно монолитных, в том, что неизвестно, какую существующую функциональность может сломать свежедобавленная фича или пофикшенный баг.
Вот эту проблему решают автоматизаторы. Они пишут автотесты, проверяющие уже работающий код и сваливающие в лог все найденные ошибки. Поэтому работа автоматизаторов делится на две большие части — написание автотестов и чтение логов этих автотестов. По результатам логов они заводят дефекты и разработчики их правят.
Пишут автотесты они на скриптовых языках, прежде всего на Python и JS. Используют массу инструментов, например, Selenium и Protractor.
Есть ещё такая субспециализация автотестеров как нагрузочники. Эти ребята умеют эмулировать большой поток обращений пользователей к различным модулям системы и мониторить поведение этих модулей под нагрузкой. Тоже крайне полезные люди.
В рамках разработки ПО вы будете сталкиваться, в основном, с дизайнерами интерфейсов. А в целом, дизайнеров множество видов и они друг на друга непохожи (работа дизайнера интерьеров в корне отличается от, например, промышленного дизайнера и вообще не похожа на работу дизайнера-иллюстратора). Вообще, надо различать UX и UI специалистов, однако в моей практике эти роли всегда совмещал один человек.
Функция UX (User Experience) ближе к аналитикам. В рамках этих задач дизайнер определяет, как будет работать интерфейс, его логика. Как сделать, чтобы интерфейс был максимально простым, не вызывал у пользователя желание обратиться в саппорт.
Функция UI (User Interface) уже чуть более «творческая». В рамках этих задач дизайнер определяет, как будет выглядеть интерфейс, его внешний вид. Эти функции неотделимы.
Так как проработка дизайна в том виде, в котором он будет готов для вёрстки, требует много времени, дизайнер интерфейсов должен уметь рисовать «вайрфреймы». Это такие наброски интерфейса, которые можно набросать за несколько часов и по которым уже можно судить, насколько это будет удобно использовать.
Дизайнер должен уметь собирать кликабельные прототипы, так как полнота ощущений от просмотра картинок и от непосредственно кликанья приложения, сильно отличается.
Долгое время основными инструментами дизайнера интерфейсов считались фотошоп и иллюстратор, но потом их заменил Sketch, а в последние годы Figma, позволяющая контролировать процесс подготовки дизайна в реальном времени и легко оставлять комментарии прямо поверх макета.
Бизнес-аналитики встречаются как в продуктовой, так и в заказной разработке на проектах с большим количеством сложных и пересекающихся требований. Основная задача такого специалиста — вытащить требования из заказчика, обдумать, задать правильные вопросы, уточнить непродуманное и всё это изложить в понятной для разработчиков форме.
Этот специалист способен взять на себя всю работу с требованиями (однако вам всё равно нужно их рецензировать), сильно облегчив вашу жизнь, потому что если компания экономит на аналитиках, с требованиями работать вам.
Ценны аналитики, разбирающиеся в предметной области проекта, их польза сильно возрастает, но в целом, они универсальны и умеют разбираться в неизвестных предметных областях.
Основным инструментом аналитика является его аналитический мозг. Остальные специалисты тоже используют мозг, но не так активно, по большей части заменяя его гуглом, аналитик же мыслит много, глубоко и разлаписто. Из технических инструментов эти ребята используют Confluence (в модных стартапах чаще Notion), всевозможные рисовалки бизнес-графики для диаграмм, интерактивные доски вроде Miro.
Иногда мутируют в аналитиков бизнес-процессов, это больше не про проекты, а про регулярное производство и несколько выходит за рамки этой статьи. Аналитики, имеющие страсть к управлению, становятся нашими коллегами, пиэмами.
Системные аналитики встречаются там, где нужно создавать сложные информационные системы и сильно облегчают жизнь разработчикам тем, что, обладая глубокой технической экспертизой, помогают проектировать технические решения.
Для системного аналитика не составляет проблемы накидать модель данных для сложной системы или даже спроектировать структуру базы данных, которую разрабу останется только импортировать. Может составить детальный алгоритм работы отдельного модуля или целого приложения.
Особенно полезны в интеграционных проектах. Могут изучить систему, с которой нужно интегрироваться, её API и составить план интеграции и методы, которые разрабам останется только закодить.
Основной недостаток этих ребят только в том, что они чрезвычайно редки, так как имея нужный уровень технической экспертизы, можно переквалифицироваться в аналитика-программиста и зарабатывать сильно больше.
Обычно при слове «сисадмин» люди представляют грустного бородатого человека в свитере с оленями, который заправляет картриджи и перезагружает роутер. На самом деле, сисадминов множество видов и они отличаются друг от друга ещё больше, чем различные дизайнеры.
Сисадмин в компании по разработке не заправляет картриджи и не переустанавливает винду, а сидит в хорошем кресле и строит инфраструктуру из консоли. Закупает серваки в датацентрах, разворачивает на них виртуальные машины, конфигурирует различные веб-сервисы, тоже не выходя из консоли. Когда нечего делать, администрирует корпоративный домен, выдаёт новоприбывшим сотрудникам доменные учётки.
Хорошие сисадмины умеют кодить на некоторых специфических языках, чтобы автоматизировать свои задачи и как можно меньше работать руками.
В целом, они как электрики, вы с ними будете взаимодействовать редко, но без них жить невозможно никак.
О девопсах неайтишные заказчики знают ещё меньше, чем о представителях других специальностей. Профессия появилась относительно недавно, представители её ценятся чрезвычайно, так как сильно облегчают разработке жизнь.
Эти ребята могут разворачивать процесс непрерывной интеграции и развёртывания при помощи разных инструментов — Git, Docker, Kubernetes, уменьшая тем самым головную боль программистов. Автоматизируют процессы в Jira, уменьшая головную боль всех остальных участников процесса и повышая связность системы. Также настраивает мониторинг всех развёрнутых контуров, контролирует работоспособность.
В разработке высоконагруженных приложений, девопсы бесценны.
Достаточно редкие звери в современной разработке, за 13 лет работы я встречал выделенного dba-шника всего один раз. Нужен там, где много баз данных, все они здоровенные и критически важные.
Помогает в проектировании сложных баз данных, занимается оптимизацией готовой БД, организует грамотное архивирование и восстановление в случае аварии, делает разграничение доступа к БД.
Чаще всего же на dba экономят и всё это делает девопс или сисадмин.
Контентеры чаще встречаются в социальных сетях, где генерят всевозможные смешные видео и мемчики, но может возникнуть необходимость поддерживать какой-нибудь разлапистый корпоративный сайт и вот там вы столкнётесь с контентерами, которые умеют намного больше.
Основой смысл этой профессии — сделать так, чтобы относительно дорогие программисты не занимались правкой текстов и картинок на сайте, а делали это относительно дешёвые контентеры. Хороший контентер не только досконально знает свою CMS, но и имеет зачаточные знания вёрстки и работы с изображениями, чтобы их, как минимум, к публикации готовить.
Особенно весело, когда на сайте часть информации сделана средствами CMS, часть хардкодом и нужно поменять и то, и то.
Маркетологи, ещё не мутировавшие в продактов, тоже могут вам встретиться, в основном, в качестве внутренних заказчиков в продуктовой разработке. Часть их работы выражается в придумывании различных маркетинговых акций, для поддержки которых нужен департамент разработки.
Например, вас могут попросить реализовывать нетипичный интерактивный элемент на сайте, лендинг (обычно по готовому дизайну, с чёрным фоном, конечно же), современный маркетолог может запросить ещё и телеграм чат-бота.
Особенность работы с ними, в основном, в прибитых гвоздями дедлайнах, так как маркетинговые акции часто привязываются к календарным праздникам.
Техпис тоже относится к категории специалистов, облегчающих вашу работу. Чаще всего он себя берёт написание различных пользовательских инструкций. Хороший техпис умеет снимать и готовить к публикации скринкасты с демонстрацией функций продукта и грамотно писать объёмные документы, не путает тся и ться, функциональность и функционал (функционал, это штука из математики, в продукте же функциональность)
Также техпис следит за связностью и консистентностью корпоративной базы знаний, потому что конфлю без присмотра быстро превращается в плохоструктурированную свалку информации.
В одной компании я встретил техписа, который кроме основной деятельности, делал ещё еженедельную корпоративную рассылку с новостями проектов, мемасиками, общекорпоративными новостями, просто полезными заметками. Было достаточно интересно по пятницам такую рассылку читать.
Чаще на техписе экономят и инструкции пишет либо кто-то из аналитиков, либо вы.
Нужно чётко разделять СБ и ИБ, это разные вещи. СБ — это в большей степени оффлайновая служба. В неё входят вахтёры на входе, всевозможные охранники и люди, делающие пробив по разным базам кандидатов на ответственные должности в компании. С ними вы контактируете один раз, при трудоустройстве. В американских фильмах ещё часто показывают, как уволенный сотрудник покидает офис с коробкой личных вещей в сопровождении СБшника, у нас такого никогда не видел.
ИБ — это уже чисто айтишники.
Игнорирование распоряжений ИБшников ведёт к сливу персональных данных и прославлению компании в новостях и соцсетях (говорят, правительство готовит оборотные штрафы за это, потому что сейчас штрафы смешные), а в худшем случае — к сливу служебной информации конкурентам или поражению инфраструктуры вирусом.
В общем, с этими ребятами надо дружить.
Есть множество специальностей, для которых вертикальный рост необязателен. К примеру, можно до пенсии руководить отдельно взятыми проектами и прекрасно себя чувствовать. Однако у некоторых сотрудников таки есть карьерные амбиции, но они совершают одни и те же ошибки, основных четыре штуки, о них и поговорим.
«Никогда ни о чём не просите, особенно людей, которые сильнее вас. Сами предложат и сами всё дадут» — совет Воланда работает только с п**лями.
Неизвестный автор
Совершенно верная цитата. Ваш руководитель, скорее всего, слишком занят, чтобы заниматься телепатией и угадывать, кто из его подчинённых хочет занять более высокую позицию. Когда открывается такая вакансия, он обычно выбирает из тех, кто открыто говорил ему о том, что хотел бы повышения.
Нужно уметь выбрать момент, когда это будет уместным, но сообщать руководителю о том, что вы имеете карьерные амбиции, надо и надо это делать периодически. Да, вероятность того, что повысят именно вас, невысока, но если вы будете молчать, точно ничего не выйдет.
Мы не корпорация. Мы семья.
Один из моих бывших работодателей
Конечно же, надо гуглить информацию о компании, в которую собеседуетесь. И на интервью обязательно нужно задать вопрос о том, растёт ли данная компания. Если в ней десять лет назад работало двадцать человек и сейчас работает столько же, шансов получить повышение в ней немного.
Особенно это касается компаний семейного типа. Там на всех руководящих должностях всегда будут родственники и близкие друзья гендира и человек со стороны никогда не вырастет.
Хотите вырасти — идите в растущие организации, в которых постоянно открываются новые направления и бизнес-единицы. Это не даёт никаких гарантий, более того, у такой компании выше риск обанкротиться, но это даёт шанс.
Успех — это умение двигаться от одной неудачи к другой, не теряя энтузиазма.
Черчилль.
Получив отказ отказ в повышении, сотрудник испытывает соблазн сыграть обиженку и начать итальянскую забастовку. Ни к чему хорошему это не приведёт. В лучшем случае руководитель её просто не заметит, а в худшем у сотрудника будут проблемы.
В статье о безответственных сотрудниках я писал, что если человек употребляет фразу: «Не нравится, как я работают — увольняйте», его надо аккуратно и быстро уволить.
Тот же принцип работает с сотрудниками, предлагающими ультиматумы, вида: «Не повысите меня — уйду к конкурентам». В Японии нет терроризма, потому что японские власти принципиально не ведут переговоры, а сразу этих террористов уничтожают, иногда вместе с заложниками, что делает терроризм бессмысленным. С бизнес-террористами тоже не нужно вести переговоры.
Взял навскидку три серьёзные вакансии менеджера проектов на хедхантере:
Таких вакансий не 100 %, иногда работодатели этого не требуют, но чаще наличие диплома предполагается.
Самый распространённый миф среди соискателей на постсоветском пространстве — что люди, протиравшие пять лет штаны в вузе уступают по профессиональным и человеческим качеством людям, начавшим работать сразу после школы.
На самом деле, у обладателя диплома гарантированно есть следующие качества:
Он более усидчив. Может продолжительное время работать, не видя практических результатов своей работы. На длинных проектах со сложной архитектурой, это важное качество.
Он совершенно точно адекватен как человек. Неадекватные вылетают после первой-второй сессии с гарантией.
Умеет работать с большим количеством информации, вычленять главное. Я считаю, что навык систематизации хаоса важнейший для пиэма.
Он более находчив, так как в процессе учёбы постоянно сталкивался с разными сложными ситуациями. Более социализирован, так как для множества учебных проектов нужно объединяться с другими студентами. Так как современные проекты чаще всего делаются в команде, не последний по важности навык.
Да, вы можете отправиться работать после школы, но в этом случае, вам будут доступны только исполнительские должности. Когда разговор пойдёт о том, кого сделать руководителем, начальство выберет человека с дипломом. Есть вариант не работать по найму, а сразу же начать свой бизнес, но увы, качествами, необходимыми для предпринимательства, обладает очень мало людей.
Доводы при Биллов Гейтсов и Стивов Джобсов, бросивших университеты — чистой воды казуистика, таких людей ещё меньше.
Билл Гейтс родился в Сиэтле (штат Вашингтон), в семье корпоративного адвоката Уильяма Генри Гейтса II и члена совета директоров First Interstate Bank, Pacific Northwest Bell и национального совета USWest, United Way Мэри Максвелл Гейтс. Его прадедушка был мэром и сенатором, а дедушка — вице-президентом Национального банка.
википедия
Это довод больше не к пиэмам, а к разрабам относится. Дескать, зачем учить устаревшие технологии, когда можно сразу взяться за язык и фреймворк, которые будут использоваться на данном конкретном проекте.
К сожалению, подход «взял и изучил» не работает ни для разраба, ни для пиэма. Разраб без фундаментальных знаний не сможет продумать грамотную архитектуру, он может просто не знать о том, что большая часть работы над кодом сводится к обработке граничных случаев, не имеет привычки сначала проектировать, потом говнокодить и так далее.
Пиэм для того, чтобы правильно спланировать проект, должен разбираться в бизнесе и основных экономических законах, без этого он будет просто переносчиком галлюцинаций заказчика в проектные документы.
Да, предметы, вроде основ библиотечной культуры с каталожными карточками, физкультуры, философии или права, прямой пользы не дадут, но они помогут сформировать более полную картину мира и не стать плоскоземельщиком, антипрививочником или сторонником гомеопатии.
Вышку в вакансиях требуют, чтобы отсеять некоторые категории людей:
01
Людей с фрагментарными знаниями, но большим самомнением.
02
Неадекватных, плохосоциализированных людей, которых будет трудно вписать в команду.
03
Ленивых, немотивированных, плохо концентрирующихся людей, не любящих узнавать и учиться новому.
Да, установка этого фильтра приведёт к тому, что в компанию не попадут самородки, которые освоили всю фундаментальную базу без университета и при этому умеют работать в команде, но таких людей очень и очень мало.
Все вы видели картинки про лидера и босса. Мне как-то больше попадались именно боссы, думающие о прибыли в ближайшей перспективе. По максимуму сократить издержки (например, заменить в туалете бумагу на однослойную), нанять самых дешёвых исполнителей, которым можно корпоративным популизмом загадить мозги и заставить пахать. Если что-то не нравится в работе сотрудника, сообщить ему об этом словами, ртом — слишком сложно. Лучше уволить и потратить эквивалент его полугодовой зарплаты на найм и индакшен нового. Повысить на сто долларов зарплату имеющемуся сотруднику тоже моветон, лучше пусть он сам уволится, а мы новому будем платить больше на пятьсот. Ну, вы все прекрасно знаете таких боссов.
Давайте разберём разницу между лидерами и боссами более подробно. Картинки взяты из pdf-ки officevibe, если у вас хорошо с английским, оригинал тут.
Профессия руководителя в топе по количеству попадающих в неё психопатов. Встроенный скилл нулевой эмпатии позволяет этим людям быстро делать карьеру, как в бизнесе, так и в госкорпорациях. Психопат на государственной должности — это вообще, очень российские реалии.
Настоящий лидер же эмпатичен и сопереживающ, для него важен каждый сотрудник, он играет не в шашки, а в шахматы, понимая разницу между фигурами. И босс, и лидер, могут заставить сотрудников поработать сегодня допоздна, потому что завтра релиз, но только лидер закажет им пиццу и энергетики.
Ушли времена, когда продукты делали гении-одиночки. Современные продукты выпускаются слаженными командами, в которых есть командный дух. Кто-нибудь может сказать без гугла, кто сейчас CEO Кока-Колы? А этот продукт потребляют все. Лидер хорошо понимает этот момент и поддерживает даже на уровне лексики, чаще говоря «мы сделали», а не «я сделал».
Самый большой страх молодого руководителя — что подчинённые накосячат. И ему кажется, что лучшим решением будет требовать, чтобы каждый Вася давал ему на вычитку все отправляемые клиенту документы, все таблицы на рецензирование и вообще, отчитывался за каждый чих. Такой подход не только демотивирует сколько-либо самостоятельных людей и грозит тем, что в команде останутся только дуболомы, умеющие работать только под таким плотным контролем, но и приводит к тому, что при попытке масштабироваться, такой руководитель утонет в микроменеджменте.
Контролировать надо, без контроля система рассыпется. Прочитайте заметку о контроле и применяйте его правильно. Но не микроменеджерите, делегируйте. Да, кроме описанного выше страха, у вас может появиться страх, что из-за чрезмерного делегирования кто-то из подчинённых вас подсидит. Поэтому не делегируйте четыре вещи, которые нельзя делегировать.
Страх — плохой мотиватор. Под руководством человека, излучающего страх, можно проработать какое-то ограниченное время, подзаработать и найти нормальную работу, где лидер излучает доброжелательность и уважение.
Да, третирующий подчинённых Джобс, достигал определённых успехов и выпускал революционные продукты, но его Apple был неустойчив, а порой и убыточен. Apple Тима Кука, излучающего доброжелательность, рвёт по капитализации все компании мира.
Да и в целом, приятнее после рабочего дня чувствовать вдохновение, а не выжатость. Лидер проявляет уважение к сотрудникам и взамен они быстро начинают уважать его.
Не совсем о лидерстве, но всё равно, важный пример из жизненного опыта. Я испытал лёгкий шок, когда оказалось, что в университете преподаватели обращаются к нам на «вы». После школы, в которых к нам обращались на «какое же ты дерьмо», прямо возникало ощущение, что ты уважаемый человек и желание учиться появлялось само собой.
— А вы не боитесь, что они выучатся и уволятся?
— Я боюсь, что они не выучатся и останутся.
Боссу некогда развивать людей, он занят выжиманием из них краткосрочной прибыли, чтобы отчитаться перед большими боссами о выполнении кипиай и получить свой ненаглядный бонус. Людей он рассматривает исключительно как ресурс.
Лидер не жалеет времени на то, чтобы вглядываться в подчинённых, находить их сильные стороны и предлагать варианты развития этих сильных сторон. Он периодически проводит встречи один на один и не только сообщает сотруднику, где и как он накосячил, но и как ему развиться в более крутого специалиста.
Если у рядового сотрудника есть опция «собрать жопу в горсть и запилить фичу за ночь» (хоть я такое и не приветствую), то менеджер такой опции, как правило, лишён. Но если вы на собрании будете твердить, что все должны в ближайшие дни жёстко повпахивать, а сами отправитесь играть в гольф, уважать вас перестанут.
Даже на удалёнке, если вы потребовали от программиста не ложиться спать, пока не исправит важный дефект, сами оставайтесь на связи, пока он не отпишется о готовности, чтобы при необходимости ответить на его вопросы, а в конце перепроверить, всё ли он правильно поправил.
Внутри вашей команды должно быть чёткое распределение обязанностей и ответственности. Накосячивший сотрудник должен свой косяк исправить, это самое лучшее и адекватное наказание. Но для внешних людей и, в особенности, руководства, вину за ошибки всегда берёт на себя менеджер, такова особенность его работы. Боссы же ведут себя наоборот и стараются свалить вину на кого-нибудь, даже если виноваты сами.
Успех же лидер напротив, делит на всю команду и подчёркивает, что это общее достижение, даже если сам сделал большую часть работы.
Боссов было много в девяностые. Взять у первого клиента предоплату за крупную партию товара, потом у второго другую предоплату, у третьего третью, купить джип «Гранд Чероки» и десять ящиков водки, джип разбить, офис заблевать, быть застреленным. Сейчас времена стали поцивилизованней, но боссы, всё равно, сосредоточены на целях, максимум, ближайшего квартала. Очень мало кто думает на год вперёд, а план на десять лет есть, вообще, у единиц.
Да, реалии нашей страны диктуют краткосрочное планирование, но лидера без стратегии, всё равно, не бывает.
Лидеры любят плоские структуры и бирюзу. В моей любимой айтишечке, в большинстве компаний, вообще, меритократия и власть обретают те, кто более компетентны, зачастую без официальной должности. Поэтому в айти плохо приживаются менеджеры-вайтишники из других предметных областей. Если разработчик не чувствует в вас коллегу-айтишника, подчиняться вам ему будет трудно.
Будьте лидерами, а не боссами.
Секрет управления людьми в том, чтобы отделить тех, кто ненавидит вас, от тех, кто еще не принял окончательного решения.
Кейси Стенгел
Давайте разберёмся, что такое наказания в менеджменте и как их применять. Начнём с того, что наказание применяется не для удовлетворения садистских наклонностей менеджера, а для того, чтобы сотрудник, плохо выполняющий свою работу, стал выполнять её лучше.
Менеджеры, которым приходилось подчиняться мне, в основном, применяли два вида наказания: депремирование и увольнение.
По ТК РФ уменьшать сумму оклада у сотрудника нельзя, поэтому при трудоустройстве часто применяется финт. У сотрудника спрашивают, сколько он хочет зарабатывать. Он отвечает, что x руб. Ему предлагают 60 % от этой суммы в виде оклада и 40 % в виде переменной части, успокаивая, что эта переменная часть практически всегда выплачивается полностью. Сотрудник провинился — к нему применяется уменьшение переменной части. Особенно этим славятся руководители, под руководством которых работают неквалифицированные сотрудники. Если хотите узнать об этом подробнее, посмотрите видео с канала «Все работы хороши». В отдельных компаниях применяются такие хитрые схемы оплаты, что сотрудник при определённых условиях может проработать месяц бесплатно или остаться компании должен.
Но мы-то с вами управляем не сотрудниками склада и не официантами, а высокооплачиваемыми, творческими и довольно востребованными на рынке труда людьми. То есть, вы платите такому человеку определённую сумму. Он косячит. И чтобы он косячил меньше, вы решаете заплатить ему поменьше. Что может вызвать такое действие? Только озлобление и открытие в фоновой вкладке хедхантера и линкадина.
Я поступал честнее. Сотрудник хочет получать x рублей. Я же предлагаю ему x в виде оклада и возможность заработать до x+30 %, если он выполнит определённые условия. Вот лишение части этих 30 % воспринимается намного спокойнее.
Повторим для закрепления. Не лишаем сотрудников тех, что и так должны им заплатить по изначальной договорённости, а предлагаем возможность заработать больше и в случае косяков, лишаем их этих денег.
Если незакрытие испытательного срока сотруднику, хоть и несёт определённые расходы для бизнеса, но они невысоки (почитайте, как правильно увольнять по итогам испытательного), то увольнение сотрудника, проработавшего более серьёзный срок, будет стоить компании, по ощущениям, где-то его полугодовую зарплату.
Помимо потерянных денег на индакшен и онбординг этого сотрудника и затрат на рекрутинг нового, есть ещё риск, что, не поменяв процедуру найма, вы наймёте ещё одного косячащего сотрудника и потеряете эту сумму ещё раз.
На мой взгляд, увольнять нужно людей, нанёсших компании ущерб сознательно. То есть, человек, чётко понимая, что делает, нахамил ключевому клиенту, продал базу конкурентам или организовал распильно-откатную схему. В таких случаях увольнение оправдано, в остальных же лучше обходиться менее радикальными методами.
На этом арсенал наказаний 95 % руководителей заканчивается. Мы же разберём ещё несколько разновидностей.
Одна из причин, по которой специалисты идут в вашу компанию — интересность задач, наличие задач с техническим вызовом, что-то, для чего им нужно напрячь мозг и проявить творческое мышление.
И если в качестве поощрения, можно наоборот, направить отличившегося специалиста на интересный проект, то в можно и в качестве наказания поступить наоборот. Одним из плюсов это подхода является то, что грамотный, но накосячивший специалист, может неинтересную задачу автоматизировать.
Для сотрудников, которых мотивируют интересные задачи, такой метод наказания может оказаться эффективным и из-за временного характера не вызвать озлобление. Другое дело, что если он у вас и так джейсоны перекладывает, менее интересной его работу вы уже не сделаете.
Крайне редко применяемый, но в ряде случаев могущий оказаться эффективным метод. Временно заставить удалёнщика работать в офисе, временно заставить офисного работника работать из дома. Перевести в другой кабинет, лишить дополнительных мониторов. Способ сложен из-за того, что вам нужно знать, что из окружения важно для этого специалиста.
В твиттере был шуточный тред о системе офисных пыток:
Я, кстати, разрабатываю систему офисных пыток.
— Рептилия Оля (@yashcheritsa) May 7, 2018
1. Монитор провинившегося сотрудника подключают к проектору на день.
2. Все столы ставят амфитеатром, провинившегося сотрудника сажают работать в центр спиной ко всем.
Заниматься откровенным садизмом, конечно, не стоит, но грамотно и тонко применив подобный метод вы можете добиться определённого успеха.
Этот метод работает для сотрудников, которые ценят самостоятельность в принятии решений. Я ранее писал, что большинство решений должно приниматься на нижнем уровне. Вы можете временно изменить местонахождение сотрудника в этой пирамиде, лишив самостоятельности.
Неделя под директивным управлением послужит самостоятельному сотруднику хорошим уроком и количество косяков снизится.
А вот этот метод я применяю постоянно, озвучивая, что ответственность в нашей компании выражается в том, что накосячивший должен самостоятельно свою ошибку исправить. То есть, если продукт ведёт себя не так как нужно, ошибку исправляет сотрудник, ответственный за модуль, который вызвал ошибку. Никаких исключений. Метод обычно нормально воспринимается сотрудниками и хорошо работает.
Не работает на хронических косячниках, у которых на исправление собственных ошибок уходит большая часть рабочего времени. Но тут нужно задуматься, нужны ли вам такие сотрудники вообще.
Предположим, ваш сотрудник по какой-то причине на даёт ни однократного, ни повторяемого результата. Часть задач делает, но большинство на нём зависает. Или вообще, не перформит ничего.
Я читал историю американского senior джависта, который, благодаря высокому скиллу, проходил собеседования, устраивался сразу в десяток компаний и либо ничего не заливал в гит, либо заливал какую-нибудь ерунду для вида. Через месяц его увольняли, но сениорскую зарплату за этот месяц выплачивали, потому что никто не хочет исков. Ну и чувак таким образом зарабатывал отличные деньги.
В РФ в последнее время всё чаще оформляют по трудовой и такой финт затруднителен и представляет скорее экстремальный случай, но вы можете столкнуться с низкой производительностью и у вполне честного сотрудника, работающего только на вас.
Большинство руководителей такого сотрудника сразу же увольняет, но такой подход несёт в себе риск, что если не поправить процедуру найма, место этого сотрудника может занять другой, такой же не перформящий сотрудник. Давайте разбираться.
Вариантов всего два. Сотрудник данную задачу либо не может, либо не хочет сделать.
Может быть, задача нетипичная для проекта, может быть, при найме сотрудника проморгали или сознательно забили на отсутствие одной или нескольких компетенций.
Рекомендую в таких ситуациях привлечь лида и провести полноценный ассесмент данного сотрудника.
Если пробелы единичны, поднять его квалификацию, проведя одну или несколько консультаций с тем же лидом.
Если же пробелов много, аргументированно объясняем сотруднику, что он не соответствует занимаемой должности и компания с ним прощается. После этого анализируем и корректируем процедуру найма, чтобы такие люди больше в компанию не попадали.
Этот вариант несколько сложнее, потому что речь идёт о мотивации. Может быть, сотрудник считает, что такие задачи должны выполнять другие люди или его руководитель. Может быть, он не считает задачу важной для компании. Может быть, он считает её скучной.
Выясняем конкретную причину разговором один на один и принимаем решение. Объясняем, что эта задача на самом деле его обязанность (подтвердив свои слова должностной инструкцией), извиняемся и передаём задачу другому сотруднику. Объясняем, что задача на самом деле важна для компании и у её результата, на самом деле, множество потребителей, просто он об этом не знает. Со скукой работать сложнее, но тоже есть варианты. Может быть, дело в выгорании, может быть, сотрудник перерос свою должность и его пора повысить или перевести на проект посложнее.
Многие новички в менеджменте задаются вопросом — как перестать быть мягким управленцем, научиться махать шашкой и заставлять всех этих лентяев работать. Может прозвучать парадоксально, но если вы от природы мягкий человек, для того, чтобы стать успешным руководителем, вам не нужно становиться жёстким.
Бытует мнение, что мягкий менеджмент не работает, но это исключительно от недостатка навыка.
Во-первых, изображая жёсткость, будучи мягким человеком, вы будете выглядеть неконгруэнтно и вас не будут воспринимать всерьёз. Сложное слово «конгруэнтность», даю расшифровку:
«Конгруэнтность — это соответствие, согласованность внутреннего содержания человека (его установок, взглядов, эмоций и чувств, состояний, переживаний) и его внешних проявлений — поведения, вербального выражения своих чувств и эмоций. Это состояние, в котором человек наиболее достоверен и аутентичен в качестве самого себя — в противоположность тому, чтобы проявлять психологические защиты, предъявлять некоторый фасад, прятаться за маской, играть какую-то роль»
Яна Падерина, клинический психолог, специалист НКО «Ассоциация «Мир общения».
А во-вторых, мягкий и нетребовательный — не синонимы, в этом великий инсайт этой заметки.
Весь секрет заключается в том, что вам нужно мягко, спокойно и системно применять основные инструменты руководителя, одновременно с этим формируя вокруг себя команду людей, которым будет комфортно работать именно с мягким руководителем.
Совершенно верно, есть люди, предпочитающие «сильную руку» и наоборот, есть люди, ценящие хорошее отношение и высокую степень свободы. И в айтишечке вторых большинство, особенно среди людей, которые выбрали эту профессию осознанно, а не в погоне за якобы лёгкими деньгами.
Что же это за инструменты, которые нужно применять?
То, что приоритеты компании понятны вам, совершенно не означает, что они понятны (и даже известны) вашей команде. Пример не из айти. Ни одни олимпийские игры за последние лет двадцать не уложились в бюджет. Но все они состоялись вовремя. Потому что для олимпийских игр сроки более приоритетны, чем бюджет, и это не всем очевидно.
Спокойно, мягко и системно, а главное, периодически, доносите верхнеуровневые приоритеты компании до сотрудников и убеждайтесь, что они их понимают и разделяют.
Пока сотрудников немного, формируете с каждым из них среднесрочный и краткосрочный план. Допустим, на спринт и на день. Важный момент. План пишет сотрудник, вы его только рецензируете. Придумывать сотруднику ничего не нужно, задачи он может взять из числа запланированных в спринт. Личный план на спринт должен быть средней детализации, не просто перечень задач, но и более мелкие действия. План на день должен быть более детальным. Все планы должны фиксироваться. Лучше, если это будет онлайн-инструмент.
Если вы будете спокойно и мягко настаивать на составлении планов, постепенно сотрудники научатся составлять эти планы и их дисциплина возрастёт.
Контролировать исполнение планов нужно обязательно. Для контроля исполнения ежедневных планов достаточно дейликов. Для контроля спринтовых планов — процедуры обзора спринта. Постепенно будут выделяться сотрудники, неспособные работать в таком режиме и требующие микроменеджмента. С ними поступаем по батыревски — учим, лечим, мочим.
Если вы будете спокойно и мягко контролировать, сотрудники быстро поймут, что увильнуть от исполнения планов у них не получится и дисциплина возрастёт.
За хорошее хвалим, за плохое ругаем. Делаем это с определённой периодичностью. Ругаем не человека, а то, что он сделал. Хвалим публично, ругаем лично. В привычной манере раскладываем результаты работы каждого сотрудника по полочкам и объясняем ему, что в его работе хорошего, что плохого. Можно даже не созваниваться, а завести на каждого сотрудника гуглотаблицу с двумя колонками: «Что сделал хорошего» и «Что сделал плохого», расшарить на них и заполнять по мере поступления. Этим навыком владеют, наверное, 5 % практикующих управленцев, остальные копят обиды, а когда чаша переполняется, увольняют. Не будьте такими.
