Сложные ситуации в IT, и что с ними делать?
В этой статье разберем эмоционально-сложные ситуации, с которыми сталкиваются айтишники на работе. В конце — пара строк рекламы.
Начальство
Сверху приходят указания:
- «брось всё — делай вот это»;
- «делай вот таким способом». А способ — явно не лучший, и объяснить не получается;
- «останься на выходных» и прочий овертайм;
- «хорошо сделал — а теперь поставь git-метку, а вот в общий код не мердж». Обидно выкидывать много работы;
- «быстро заэстимейть подробно эту задачу», причем результат должен уложиться в человеко-месяц;
- «а давай внедрим KPI».
Очень грубо, причины почему начальство может давать дурацкие странные указания:
- низкий IQ. Крайне редкая причина, в айти идиоты не приживаются, а PM «по знакомству» не становятся;
- мало знаний в профильной области и нет умения окружить себя экспертами. Такое иногда бывает, хотя довольно редко;
- желание проявить власть. Иногда бывает, но всё-таки редко. Я, пожалуй, только пару примеров могу привести за 18 лет;
- адаптация — суперэксперты привыкают, что кругом все разбираются очень слабо. Поэтому привычнее сказать «сделай, как я сказал», чем объяснять, почему так. Каждому объяснишь — а работать когда?
- мало данных и понимания текущей ситуации. Вот это частая проблема. Хуже того, менеджеры часто не понимают, что данных мало, и предпочитают действовать. Что делать:
- задавать вопросы «а что будем делать, если вот так и вот так?» Скорее всего, к вам этот вопрос и вернется с формулирокой «быстренько посмотри вот это, и давай еще подумаем»;
- выводить на конкретные изменения в действиях. Т.е. если «вы должны меньше времени тратить на саппорт», то «если я весь саппорт вынесу на понедельники, это ок?».
- менеджеры, которые выросли из программистов, часто имеют особенности:
- самим хочется покодить, а некогда;
- теряется техническая квалификация, но заметить это некогда;
- их повысили за умение писать хороший код, а дальше хороший код писать некогда и не получается. Начинаются нервы «я должен писать код, я не пишу код, я плохой сотрудник» и включается защита.
- те, у кого есть склонность к перфекционизму, пытаются контролировать всё. Микроменеджмент убивает.
- у начальства слабые навыки донесения своей мысли: «ну там это, ну вот, я хотел сказать о, сделай как я уже говорил»;
- бюрократия. К примеру, оговорено в контракте, что все должны работать на сертифицированных ноутах через RDC — и всё тут. Да, неудобно, но за это платят деньги;
- ...
Важно: я для себя вывел правило, что если человек поступает как-то непонятно, то это не он идиот, а это я пока не понял его мотивов. Я ничего не могу сделать, чтобы поменять идиота, но я могу поменять своё понимание и могу улучшить свои навыки донесения мыслей. Ну и изредка я могу уволить идиота и нанять нового, или, если речь про заказчика — сменить его на нового.
Менеджерам: одна из задач лидера — это защита команды. Защита в том числе и от начальства. Хорошо бы уметь объяснять, чем обоснованы те или иные начальственные действия. И лучше бы использовать не «они идиоты и считают, что девять женщин родят одного ребенка быстрее, чем одна», а «начальство видит, что мы не успеваем и хочет нам помочь добавлением сильного сотрудника».
«Я — идиот», «меня вот-вот уволят»
Однажды техдир довольно крупной фирмы разослал на всех сотрудников финансовую документацию, которую вообще не стоило бы показывать. Ему было очень стыдно, но ни к каким последствиям ни для него, ни для компании это не привело.
Знаете, как это бывает? Потратишь пару дней на поиск бага, а потом там оказывается какая-то мелочь — пропущенная точка с запятой или еще какая опечатка. Думаю, у всех было.
- Ощущение «я тупой» — это нормально для синьора. См. синдром самозванца и эффект Даннинга-Крюгера. Наоборот, если человек говорит: «я классно знаю Java, JavaScript, C# и Ruby» или «я классно разбираюсь в людях» — это наверняка джуниор.
- Увольняют в IT нечасто, хотя мне довелось проходить эту процедуру неоднократно. Плюс-минус надежный способ это избежать — это регулярно, раз в несколько месяцев спрашивать начальство: «как я работаю?» и «что я могу сделать лучше для повышения зарплаты?».
- Менеджерам: ваши сотрудники точно время от времени чувствуют себя идиотами. В этот момент им надо:
- сначала дать поддержку: выслушать, напомнить предыдущие достижения, еще раз выслушать. Про цепочку отрицание-гнев-торг-депрессия-принятие многие читали, впрочем, стадии могут идти и в другом порядке. Дать поддержку — это правильно по-человечески и оправдано с бизнес-точки зрения тоже, ведь человек вернется в рабочее состояние;
- воспользоваться случаем, и вместе поискать ответ на вопрос «как такое предотвратить в дальнейшем?». Как раз после эпических провалов проще всего начать делать code review, ранние демки, синкапы, парное программирование и прочие сложновнедряемые практики.
Зарплата: «мне переплачивают» и «мне недоплачивают»
Мысль «мне недоплачивают» возникает тогда, когда долго нет провалов и негативной обратной связи. «Переплачивают» — тогда, когда две недели с каким-то пустяком провозился.
Среднюю зарплату проще всего проверить на jobs.dou.ua. Если есть большое отклонение — только тогда опасения обоснованы. Ну и если фирма разоряется, то увольнение тоже вполне реально.
Менеджерам:
- следите за попаданием з/п сотрудников в общий коридор:
- большинство склонно переоценивать свою ценность на рынке труда. С другой стороны, зарплаты растут, и сегодняшнего вашего миддла запросто переманят на з/п синьора;
- когда люди получают оффер от другой фирмы на +20% зп, а потом контр-оффер от своей на +30%, то они обижаются. Ну действительно, раньше +10% получить не получалось, а теперь сразу +30% предлагают?! Такой контр-оффер — это решение на несколько месяцев, да еще и когда станет известно другим сотрудникам — их сильно демотивирует.
- в любой компании примерно половина сотрудников смотрит на другие фирмы. Что вы будете делать, если кто-то из ключевых уйдет? Погуглите про bus factor.
Хочу открыть свою фирму
Двукратная разница между стоимостью часа, которую выставляют заказчику и часа зарплаты — это более-менее норма. Эта разница оплачивает отпуск, больничный, праздники, железо, офис и т.д. И прибыли остается условных
- До момента, когда у вас в штате не будет 8 программистов, прибыльнее получать зарплату. Это оптимистичный сценарий.
Конечно, своя фирма или фриланс дают чувство свободы, которое сложно получить, выполняя указания начальства.
Менеджерам: тут важно разделять две разных ситуации:
- человек действительно планирует так поступить в ближайшем будущем, у него есть бэклог, портфель заказов, сроки и прочий бизнес-план. В этом случае нужно думать о минимизации потерь от расставания;
- для человека это бегство и самоуспокоение, особенно для людей, для которых даже организация пикника дается с трудом. В детстве такое бегство — это «вот если бы я был очень сильным» или «если бы я был очень быстрым», а сейчас — «если бы я был успешным бизнесменом». Никто не признается, что для него мечты о своей фирме — это самоуспокоение, так что тут менеджерские действия:
- поиск причины, почему человеку плохо. Сам он вряд ли осознает и скажет именно причину, скорее вас накормят поводами. Причина может быть и за пределами работы. Если же причина таки на работе — чаще всего нарушен баланс между похвалами и указаниями «вот тут неправильно»;
- поддержите человека. Выслушайте и не кормите советами.
Требуют оценить сроки
Обычно менеджерам нужны сроки. Хоть какие-то. Хоть очень примерно. Неопытные менеджеры закладывают сроки «как есть» в контракт, опытные — делают запас. Но каким бы опытным менеджер ни был бы — ему нужны цифры, от которых можно отталкиваться.
Одна из самых неправильных идей для менеджера — это вытрясти сроки из сотрудника, надавить, чтобы эстимейт был поменьше, а потом сотрудника же и наказать за срыв сроков. С другой стороны — выполнение сроков тоже нужно контролировать. Тема сложная, поэтому краткий вывод для программистов:
- постарайтесь таки помочь менеджеру оценить сроки. А если потом за срыв сроков он накажет — увольняйтесь нафиг.
Менеджерам: если человек не хочет говорить о сроках, даже приблизительную вилку — значит он чего-то боится. Скорее всего, его раньше уже кто-то возил носом по столу за срыв сроков, вот и не хочется подставляться еще раз. Здесь много подходов, и нет ни одного идеального:
- ограничивайте вилку очень примерно. «Есть ли шанс, что сделаешь за день? Нет... А за два — уже есть шанс?» и с другой стороны «Может ли это затянуться до мая? Быстрее? К середине апреля?»;
- сравнивайте, объединяйте независимые оценки от разных людей;
- используйте planning poker, метод футболок и т.д.;
- расскажите заказчику про NoEstimates :)
Заказчик меняет требования
Иногда такое бывает. Такое бывает всегда. Нужно пару раз побыть в шкуре заказчика, чтобы понять — почему так.
На проекте с фиксированной ценой есть две крайности:
- соглашаться со всеми изменениями. Проект уйдет в минус, и зарплаты вы не получите;
- отказываться от всех изменений. Многие изменения — критически важны, и никогда не знаешь заранее, что заказчика убьет.
Что делать:
- для fixed price — о любых, даже самых мелких правках — сообщать менеджеру или кто там вел переговоры о цене;
- для time & material — предупреждать заказчика о том, сколько это займет.
У Сергея Бережного был интересный цикл на эту тему.
Менеджерам: только смерть стабильна, жизнь всегда динамична. Создавайте информационный фон, который рассказывает о неизбежности изменений. Например:
- Чем тщательнее сделано ТЗ, тем больше шансов, что оно уже устарело и не нужно.
Заказчик нифига не понимает в разработке
Иногда попадаются неадекваты, которые хотят быстро, бесплатно и без глюков. Но чаще таки заказчикам нужен хороший результат за предсказуемые деньги и в предсказуемые сроки.
«Если Заказчик хочет Волшебника, то он находит Сказочника» © менеджерская мудрость
Здесь всегда соревнование между желанием чуда у Заказчика и умением объяснять у Исполнителя.
Менеджерам: если бы заказчик хорошо понимал в разработке, то он бы вас нафиг уволил. Амортизировать надо рывки с обеих сторон и объяснять странности поведения.
Приходится допиливать чужой кривой код
Заказчики, которые уже ушли от Сказочника, обычно имеют массу кода, который «почти работает, чуть-чуть осталось». Почему уходят от Сказочника?
- срывы сроков;
- масса багов и недоделок.
Какие сложности для следующего исполнителя:
— чужой код разбирать всегда сложнее. Особенно, если он написан кое-как и нет рядом живого человека, который знает «почему так»;
— заказчику уже пообещали, что тут немного осталось. Сроки не просто горят, а уже сгорели.
Какие плюсы:
- всегда можно валить на предшественников;
- заказчик уже больше склонен прислушиваться к тому, что ему говорят. Опыт со Сказочником — отрезвляет, хотя похмельный синдром тоже есть.
Менеджерам: иногда получается выбить полную переделку, а иногда у заказчика на это уже нет времени и денег. Если не получилось полный, то ползучий партизанский рефакторинг может помочь.
«Заказчик давит» и удаленная работа
Часто бывает, что заказчик давит. И часто — это побочный эффект от удаленной работы.
Почему так?
- если нет личного общения, то очень легко перестать видеть в собеседнике человека. Видеоскайп чем-то помогает, но всё равно;
- когда исполнителя нет рядом, то всё время кажется, что он бездельничает. С такими эмоциями сложно справиться. А если исполнитель еще и не отвечает моментально — то идет заполнение паузы тревожностью и раздражением. А если исполнитель еще и отвечает с паузами на неправильном английском, то вообще ужас;
- часто у человека, который беспокоится, возникает желание построить рамки: «плз, отвечай мне в течение часа в бизнес-время», «давай эстимейты», «докладывай о прогрессе раз в N рабочих часов».
Более подробно расскажу на PMDay
Конфликты
В этом разделе привел примеры конфликтных ситуаций, которые я когда-либо видел. Я твердо уверен, что про каждую из них кто-то напишет: «так не бывает, это всё придумано», а кто-то: «да, у меня такое было». Спорить не буду, у каждого свой опыт.
Неприятные задачи
Знаю классного бэкендера, который не любит Excel и сисадминство. Другой — не любит задач по саппорту. Пока они молчат о своей нелюбви к каким-то типам задач — менеджер обычно нифига не знает и не меняет.
Менеджерам: знайте, что любят ваши сотрудники, а что — нет :)
Эстетика и прочая гигиена
Можно ли на стену вешать эротический календарь? А если порнографический? Нужно ли ходить в душ после тренировки/велосипеда? Раз в сколько дней (недель) нужно менять футболку? Парням — носить футболку-сетку? Девушкам — цокать высокими каблуками и пшикаться мощными духами? Включить кондиционер или открыть окно? Есть на рабочем месте? А если апельсин (дуриан)?
Список можно продолжить бесконечно, и никакие корпоративные правила все аспекты не решат. Каждый конкретный случай нужно договариваться отдельно — и искать какие-то компромиссы.
Самая частая ошибка — это замалчивание проблемы и тихая обида, вплоть до увольнения. Бывает еще и разновидность, когда о проблеме говорят коллегам, но ни в коем случае не тому, кто может что-то сделать. На эту тему можно погуглить Эрика Берна «Люди, которые играют в игры» и «Игры, в которые играют люди» — для начала очень даже хорошо.
Менеджерам:
- стройте доверительные отношения. Заранее;
- хоть чуть-чуть покопайтесь в языке жестов. Он проще регэкспов.
Этика
С этическими проблемами мы в айти сталкиваемся реже. Хотя вот примеры:
- мне пришлось уволить UI/UX в разгар кризиса. Я знал, что у него жена вот-вот родит, но он откровенно не вписывался в рабочий процесс;
- что делать с человеком, который на корпоративном принтере и корпоративной бумаге печатает по толстой художественной книге в неделю? Меняется ли что-то, если это интерн на испытательном сроке или, наоборот, мегаэксперт, которому фирма может подарить принтер как бонус к зп? А готовы отвечать на вопрос «почему ему можно, а мне нельзя? А где это в правилах?»;
- сотрудник увлекается стритрейсингом, и других подбивает. С одной стороны — не мое дело, с другой — уже несколько раз в мелкие аварии попадал, и когда собьет кого-то всерьез — вопрос времени;
- сотрудник очень любит девушек — раньше таких называли ловеласами, теперь модно слово «пикапер». Должен ли я предупреждать девушек? Или они взрослые люди и, если что, то разбитым сердцем будут страдать вне рабочего времени? Или сделать внушение парню?
Менеджерам: как бы вы себя тут не повели — всё равно будут обиженные. Лидеры мнений здесь решают, важно организовать их диалог и не дать перейти на личности. Идите за людьми, имеющими авторитет в команде.
QA против программистов
Я в таких фирмах не работал, но вполне представляю, как такое может быть. Например, в комментах проскочила фраза: «Один джун конкретно накосячил у меня... В общем отправил его в тестеры. Наказал в общем и сильно».
Менеджерам: на мой взгляд, как только какая-то роль на проекте обозначается неважной, то начинаются обиды и дедовщина. Это здорово вредит рабочей обстановке, и такое нужно пресекать. Если вам какая-то роль не нужна — сократите её и поделите освободившуюся зарплату. А если таки нужна — уважайте.
Подчиненные
- «Добавили помощников, теперь совсем некогда работать» — очень примерно: один подчиненный требует один час в день. Новички и джуны требуют время чаще, синьоры — больше, на обсуждение серьезных вопросов.
- Судя по здесь и здесь, в украинский IT-бассейн людей втекает 20% в год, а вытекает — 5%, и мы знаем, что втекают джуниоры, а утекают синьоры, то что будет с остающимися? Правильно, процентное соотношение будет отклоняться в сторону джунов. Кто будет с этими джунами возиться? Нынешние миддлы и синьоры. Вот такая пирамида обучения.
Получать из джунов бизнес-пользу — ценность этого умения будет расти на нашем рынке труда.
Code Review
Не любят у нас code review. Часто именно за некорректную обратную связь. Чувствуйте разницу между вариантами «ты балбес» — «ты плохой программист» — «ты написал криво» — «это кривой код» — «тут лучше сделать вот так» — «можно ли с помощью лямбда-выражений сократить этот код?». Многие синьоры любят посамоутверждаться, и таки использовать «ты-» формулировки из левой части списка.
Менеджерам: прочтите, что такое конфликтогены и научитесь их слышать и быстро гасить. Умение давать грамотную обратную связь тоже пригодится.
Что изучать?
Языков / фреймворков / библиотек сейчас очень много. А времени, почему-то, мало. Что же учить? А для чего?
- Если для себя — то всё равно что. Хоть фортран, хоть монады — лишь бы интересно было.
- Если для дальнейшей работы или для трудоустройства — то лучше что-то из тех технологий, которые сейчас вверх лезут. Кмк, это JavaScript и Python.
- А если уже совсем с точки зрения прагматичной, то смотрим на рынок труда, например, djinni.
- для джунов имеет критическое значение стаж. Вы его наберете автоматически, и хорошо бы к стажу добавить еще и навыки. Очень хорошо бы.
- для синьоров технические навыки квалифицированно за час-другой не оценишь, и на первое место выходит английский. Очень печальный для меня вывод, мне английский дается с большим трудом.
При обучении темп работы падает. Если до этого все время писал на Ruby, а тут решил nodejs освоить, так на руби сервак написать всё равно быстрее выйдет. Когда еще дойдешь до такого же уровня... Дальше гуглить по «Кривая процесса обучения (А. Бандура)».
Менеджерам: виноватые и депрессивные учиться не хотят и не могут. Так что если сотрудник хочет что-то новое освоить, то часто это признак, что ему на работе хорошо. Ну или он хочет что-то выучить и уволиться, но тогда как вы об этом узнали?
Вместо вывода
В этой статье мы рассмотрели разные эмоционально-сложные ситуации, в которые попадают программисты и менеджеры. Список неполный, и решения однозначно не стопроцентные, буду рад комментам и дополнениям. Еще я провожу
