Основатель «Школы траблшутеров» Олег Брагинский со слушателями школы Виталием Лажинцевым, Павлом Куровским и Сергеем Кондратенко собрали анонимные отзывы после прочтения первой части статьи от сотрудников Ноософт. Делимся результатами без купюр.
На случай, если не хотите читать материал полностью, ниже приведены компактные формы счётчиков аспектов, волнующих программистов и проектных менеджеров.
Фидбек разработчиков
- Главное, чтобы менеджер был адекватным, стоял на стороне разработчика, а не клиента, и не спамил личку, отвлекая от работы.
- Хотелось бы, чтобы менеджеры разбирались в технологиях проекта и не требовали делать невозможного. Чаще всего МП игнорируют ограничения платформы, требуя «что-нибудь придумать, но сделать», хоть изначально понятна невозможность идти в лоб.
- Недавняя проблема: не обговорили с клиентом, как пользоваться АПИ, в итоге задача растянулась на неделю. Подготовку данных для БД от клиента не осудили, пришлось вручную заполнять обилие контента.
- Мне пока с менеджерами везёт. Кое-кто иногда может отвлекать с просьбами описать, что сделано по проекту, но понимаю, что от него это заказчики требуют, поэтому зла не держу.
- Для новичка, важно начинать проект с ТЗ, в котором описано, что хочет клиент. Не структура проекта и «додумай сам», а описанные схемы работы АПИ: математические функции, описанные этапы, пункты сбора статистики, которые планируется выгружать в дальнейшем.
Хотелось бы минимизировать ситуации «подразумевалось», «и так было понятно». При получении сторонних АПИ – желательна документация к ним и созвон с теми, кто выдал.
При старте проекта разделить задачи в битриксе на горящие и плановые: нужен функционал, а не статистика и обсуждать тайминги, чтобы не работать ночами перед запуском проекта.
- Круто, когда излагают требования ясно и чётко, и чем более структурирована информация, тем лучше. Удобно, когда за тебя многое узнают, уточняют, и не нужно искать, у кого взять информацию, спрашивать у других – можно сосредоточиться на непосредственной работе.
- Проблема менеджеров – тупят с заказчиками и неверно рассказывают суть работ. Беда, когда просьбы клиентов передают не напрямую, а пытаются придумать, что надо сделать, хотя не имеют достаточных знаний для подобных активностей.
При разработке Тиндера для спортсменов кто-то написал: «Заказчик хочет купить сервис для анализа изображений и банить контент. Просьба разработчику поресерчить, что есть.».
Мы искали сервисы. Оказалось, что при публикации приложения в AppStore есть требование о блокировке нежелательного контента за 24 часа. Просто добавили кнопку: «Блок и репорт».
Когда из-за фреймворка или технических особенностей какую-то фишку реализовать сложно, давим на то, что «этого делать не надо». Рекомендации для менеджера, если требование заказчика:
-
- необычно и не связано со вкусом – уточните: «Зачем?»
- витиевато – обсудите варианты решения с разрабом.
- Что делать менеджеру, чтобы не мешать:
- проговорить «приколы» в проекте с разработчиком, а то наобещают, а разраб страдает
- обсуждать изменения, а то что-то выдумают, а разраб узнаёт постфактум.
- Об одном из менеджеров: высокая отзывчивость и внимание к деталям. Во время созвонов следит за диалогами и попутно составляет список дел, чтобы ничего не забыть. Скорее, мне не хватает отзывчивости. Не люблю трекать время по задачам.
- Было бы круто участвовать в обговаривании сроков с менеджером. Бывает, прилетают задачи с дедлайном, которые закрыть в срок можно, лишь принеся что-то или кого-то в жертвы.
Было бы замечательно получать развёрнутое ТЗ, необходимые данные, файлы, тексты по задаче сразу, а не рыскать по фигме, в поисках картинки или тайтла нового блока.
Когда всё сделано идеально, работа становится более эффективной.
Аналитика
- Положительные черты:
- уважение ко времени разработчиков и предоставление полной информации для задач
- способность разбираться в технологиях и избегать требований, выходящих за рамки
- отсутствие спама в личных сообщениях, чтобы не отвлекать от работы
- открытость для обсуждения проблем и стремление к их решению
- способность к разбору задач и детальной проработке ТЗ
- адекватность и поддержка разработчиков.
- Отрицательные черты:
- тенденция к передаче требований заказчика без понимания технической стороны
- недооценка сложности проекта, что приводит к затруднениям для разработчиков
- недостаток отзывчивости и времени на обсуждение задач и сроков
- предоставление неполной информации и документации к задачам.
- Рекомендации:
- Уделить больше внимания обсуждению сроков и деталей задач, чтобы избежать недопонимания и спешки перед дедлайнами.
- Больше участвовать в обсуждении технических деталей с разработчиками, чтобы избежать недоразумений и уточнений в процессе выполнения задач.
- Предоставлять разработчикам более развёрнутые ТЗ и все необходимые данные сразу для увеличения эффективности работы.
- Счётчик аспектов:
- адекватность и поддержка: 4
- техническое понимание: 3
- спам и отвлечение: 2
- открытость для обсуждения: 2
- проработка ТЗ: 2
- информация и документация: 2
- отзывчивость: 1
- недопонимания и спешка: 1.
Фидбэк менеджеров
- Разработчики часто не выполняют задачи, потому что неохота разбираться или думать. Сначала сообщают, что нельзя, а в итоге, оказывается, можно!
- Воспринимают задачу так, будто её поставил менеджер и выполнение нужно тоже только ему. Но мы не придумываем задачи, всё, что передаём в работу – идёт от клиента.
Наша обязанность – контролировать исполнение, поэтому следим за ходом работ. Приходится отчитываться клиенту и отвечать, если что-то идёт не так. Когда пишем, дёргаем, спрашиваем о задаче – реагируем на клиента.
Неловко часто написывать, но, когда заказчик постоянно интересуется – выхода нет. Хотелось бы, чтобы программист был заинтересован найти решение. Не разбираюсь во всех технологиях, но регулярно опровергаю информации о невозможности реализации.
- Разработчик должен понимать, что механики придумывает клиент, МП пытается лишние хотелки отбить. Если пришли с необычностью, значит, так надо. МП не всегда понимает детали, важно объяснять подробно: программисты ошибочно полагают, что мы их понимаем.
МП находится между двух огней, но не против, а за тебя. Разрабов не дёргаю зря, лучше для них что-то сделаю, подвину сроки. Не получается – станем сплачиваться и стоять заодно.
- Больно, когда разрабы выражаются техническим языком, приходится уточнять: отвлекает и злит. Чтобы 100 раз не переспрашивать, излагайте мысли простым языком.
- Если разработчик видит, что МП требует невозможную фигню – не нужно наезжать. Предложите созвон, объясните, почему «так нельзя». Часто это желание клиента. Обозначьте рамки, когда можно писать и звонить. Вне рабочего времени – только если апокалипсис.
- Хочется открытости к обсуждению и работу над ошибками. Если поставить задачу, будем мусолить, не понимая сути, а на «как дела» отвечать «в процессе», без продвижения. Есть затыки и сложности – не замыкайтесь, спрашивайте, узнавайте, что, где и как можно сделать.
Не успеваешь доделать – не оттягивай извещение до последнего. Менеджеру отчитываться перед клиентом: либо согласуем перенос сроков, либо придумаем, как извернуться. А то в подобных ситуациях менеджер остаётся крайним, а клиент – крайне недовольным.
Злой клиент престанет давать поблажки, может затягивать с оплатой. Понятно, бывают переделки, которые съедают много времени. Надо брать волю в кулак и делать задачу, а не отписывать, что это просто бессмысленно, потому «оно не работает».
Надо сесть и разобраться, в чём дело. Сама проблема не уйдёт, её всё равно придётся решать, какой смысл откладывать до последнего. Задавай вопросы, обсуждай пути решения, но нельзя бросать. Собирай себя по частям и иди в бой на морально-волевых.
Аналитика
- Положительные черты:
- видение важности предусмотрительности и решения проблем на ранних этапах
- открытость к обсуждению и стремление к работе в команде
- позитивное отношение к развитию и обучению.
- Отрицательные черты:
- страх высказывать оценку или принимать ответственность за ошибки
- некорректное общение, включая оскорбления и переход на личности
- негативные эмоции при возникновении сложностей или несогласий
- недостаток терпения при объяснении технических моментов.
- Рекомендации:
- необходимость обучения навыкам эмоционального интеллекта для обеих сторон
- бережное отношение к общению, избежание оскорблений и грубостей
- поддержка и стимулирование командного взаимодействия.
- Счётчик аспектов:
- негативные эмоции: 8
- трудности в общении: 4
- некорректное общение: 3
- недостаток терпения: 2
- отсутствие предусмотрительности: 2
- боязнь оценки и ответственности: 1.