Традиционно эникейщик - это сотрудник техподдержки (от "press any key to continue"). Со временем так стали называть "мастеров-на-все-руки", способных и комп собрать, и сайт написать.

Сегодня хочется поговорить о том, нужно ли проджект-менеджеру быть эникейщиком в своей команде или нет?

Представим себе: вы собираете проектную команду, а параллельно от вас уже требуют делать MVP, чтобы показать клиенту. Пока что у вас в штате только разработчик, аналитика и тестировщика ещё надо нанять. Что делать?

1. Можно идти и вести переговоры: У нас пока никого нет, давайте вы подождёте, и мы все сделаем в лучшем виде. Этот подход классно работает, если бизнес не рискует потерять проект от отсутствия проактивности. 2. Можно самому во всё закопаться: написать требования согласовать, отдать в разработку и сесть за тест-кейсы. Вы действительно сможете быстро сделать проект, но, вероятно, к его качеству будет много вопросов. Для MVP может ещё как-то проканать, а вот дальше будет сложно поддерживать.

Так что же, получается, менеджер-эникейщик - однозначно лучше, чем простой проджект, умеющий только управлять?

И да, и нет: • Менеджер-эникейщик точно сможет сделать больше, чем человек без таких навыков. У него есть очень важное качество - он не боится разбираться в чём-то принципиально новом и выходить за рамки прямых обязанностей для достижения результата; • Теневая сторона - майндсет такого человека. Он будет склонен брать на себя бесконечное количество работы -> перерабатывать и выгорать, испытывать слишком сильные личностные переживания за качество проекта и страдать от провалов.

И что же делать проджекту? Лучше всего - быть эникейщиком в разумной степени. На примере кейса выше - третий вариант решения:

3. Можно замиксовать: 3.1 Активно вести переговоры с бизнесом для поиска тестировщика и аналитика. Даже если сейчас справимся без них - они нужны вдолгую; 3.2 Дисконтировать ожидания заказчика: стараемся успеть в срок, но может не получиться. Можем сделать меньше/иначе/подольше? 3.3 Писать требования вместе с заказчиком и разработчиком - так ниже шанс упустить что-то важное; 3.4 Согласовать меньший объём сценариев для проверки MVP, снизив критично важное количество тестов для старта; И так далее.

Короче, не упарывайтесь в крайности, и всё будет супер. А техническая грамотность сама по себе ещё никому не помешала 💻❤️