Фёдор Борщёв

Заметки с тегом «Работа»

Новый человек — это гипотеза

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

Этого не будет. Если такие ребята где-то и существуют, то странно, что мы нанимаем их, а не они — нас.

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

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

Игнорировать оценки коллег

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

Ради хорошей оценки мы можем даже пойти на должностное преступление — не спросить с коллеги за пропущенный дедлайн; недожать ресурсов для важного проекта; поставить в спринт неважную фичу только только потому, что попросили. Типа коллега запомнит, и на ежеквартальном ревью помянет добрым словом. Будете часто так делать — превратитесь в офисный планктон: все с вами дружат, но результатов бизнесу вы скорее всего не приносите.

Игнорируйте оценки коллег

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

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

Какие технологии выбрать для нового проекта? (версия для программистов)

Это — заметка для программистов. Если вы менеджер — почитайте версию для менеджеров.

Многие ребята, выбирая инструменты для нового проекта, начинают строить длинные таблицы, сравнивая фичи. Серьёзно обсуждают, что лучше — SFC во vue ил и CSS Modules в реакте.

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

Какие технологии выбрать для нового проекта?

А вот если вы начинаете коммерческий проект, то смотреть нужно совсем в другую сторону. Фичи — это состояние проекта сейчас. Подумайте лучше о том, каким будет ваш фреймворк потом. Удержит ли он комьюнити в ближайшую пару лет? Успеет ли за быстроизменяющейся средой? Будет ли адекватным предложение на рынке труда?

Искать ответы на эти вопросы поможет интуиция, reddit и Google Trends. И да, если вы выбираете фреймворк для фронтенда, то берите любой — всё равно протухнет через год.

Удалённая работа и контроль результатов

Иногда в командах, особенно офисных, встречаются руководители, которые вместо выстраивания чёткого конвейера, начинают мониторить странные промежуточные метрики, вроде времени прихода на работу или, ещё хуже,  времени, проведенного с открытой IDE.

Удалённая работа и контроль результатов

Так происходит потому, что спрашивать за результат — тяжело. Когда всплывает факт, что бизнес-задача не решена, приходится разбираться, кто виноват — исполнитель, менеджер, плохой\непродуманный таск, или вообще кодовая база. Тут уже возникают неприятные вопросы к самому себе — почему у меня в трекере дерьмовые задачи? Или почему у нас код — говно?

За процесс, наоборот, спрашивать легко: опоздал программист на работу на 5 минут — значит виноват. Тупанул во вконтосик в рабочее время — значит плохо работает.

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

Найм людей: лучше false negative, чем false positive

Лучше не взять хорошего специалиста, чем взять недостаточно хорошего. Особенно это актуально для небольших команд в стартапах.

Самое главное в команде — общая среда, которую еще иногда называют «корпоративной культурой». Среда может развивать ответственность у новых участников (пример — Студия Лебедева, почитайте их конституцию), а может наоборот, подавлять, как условный ЖелДорСвязьКредитБанк, где инициатива наказуема. В хорошей среде люди цветут и развиваются, в плохой — киснут.

Среду создают люди. Пока в вашей команде один участник, вся среда — это вы: команда планирует время в точности, как вы, реагирует в случае авралов как вы, выстраивает отношения с коллегами как вы.

Когда вы нанимаете людей, вы меняете внутреннюю среду — команда начинает вести себя не как вы, а как вы плюс те, кого вы наняли. Простая математика: чем меньше команда — тем сильнее каждый новый человек её меняет.

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