❗️💣 Разработчик-саботер и как не стоит делать
Сегодня хочется рассказать историю о том, как приходится поднимать проект с нуля и какие проблемы при этом могут быть.
На повестке дня стоит задача, что должна была быть реализована еще более года назад - "Создание фреймворка для обработки входящих запросов через различные протоколы и последующей их отправки к месту назначения через различные протоколы".
Кратко и по существу. Команда что будет строить приложение по обработки специализированных данных, просто должна взаимодействовать с абстракциями и ничего не знать о том, как фреймворк устроен и как он выполняет задачи. Это очень похоже на то, как работает любой фреймформ для построения современных приложений. Иначе говоря: "Сказал что, сказал чем, сказал куда, выполнил и забыл".
Задача вовсе не простая, но реализуемая и все решает грамотный анализ, планирование и действия с оценкой результатов пройденного пути.
Работа движется нормально, но у нас есть преграда - разработчик нежелающий следовать договоренностям в команде.
Да, Мистер X сперва говорит "Да!" и поддерживает решение команды, а когда приходит время оценивать результат оказывается что ничего не сделано. Хотя есть оговорка, "Сделано" просто не то что было оговорено в команде и не то, что ожидается от нас.
В конечном итоге все это ведет к срыву сроков, потери репутации команды, недовольное руководство и компания теряет деньги и клиентов.
Что же не так и как делать правильно?
Вот список действенных советов:
1️⃣ Не нарушайте договоренности в команде
2️⃣ Если все-таки хотите изменить план, подготовьтесь и обсудите с командой
3️⃣ Не шумите, если считаете что команда идет в неправильном направлении. Подготовьтесь и конструктивно изложите ваше мнение
4️⃣ Прежде чем что-либо предлагать подумайте трижды
5️⃣ Помните, команда ровняется на лидера. Не можете убедить лидера, попытайтесь убедить всех остальных по отдельности и заручиться их поддержкой заблаговременно
6️⃣ Создавать правильные ожидания от ваших предложений. Все должны понимать, что вы предлагаете и какие будут результаты
7️⃣ Не используйте персональные оскорбления, если вам не нравится человек
По сути, всё это называется "Хорошие манеры и быть чуточку умнее" и казалось бы это знать должен каждый.
Если передвинуться в настоящее время, то обстановка уже наладилась и команда перформит (англ. - perform). На прошлой неделе состоялась первая демо-сессия, где мы получили зелёный свет на подготовку еще одной демо-сессии. Если вторая демо-сессия будет также успешной, то проект получит зеленый свет для перехода из MVP в состояние полноценного проекта.
🌟 А чтобы ты сделал для изменения командного план? Пиши в комментариях.
🌟 Пиши в комментариях свои мысли, если считаешь что данный список можно расширить.
Макс Добрынин
Сегодня хочется рассказать историю о том, как приходится поднимать проект с нуля и какие проблемы при этом могут быть.
На повестке дня стоит задача, что должна была быть реализована еще более года назад - "Создание фреймворка для обработки входящих запросов через различные протоколы и последующей их отправки к месту назначения через различные протоколы".
Кратко и по существу. Команда что будет строить приложение по обработки специализированных данных, просто должна взаимодействовать с абстракциями и ничего не знать о том, как фреймворк устроен и как он выполняет задачи. Это очень похоже на то, как работает любой фреймформ для построения современных приложений. Иначе говоря: "Сказал что, сказал чем, сказал куда, выполнил и забыл".
Задача вовсе не простая, но реализуемая и все решает грамотный анализ, планирование и действия с оценкой результатов пройденного пути.
Работа движется нормально, но у нас есть преграда - разработчик нежелающий следовать договоренностям в команде.
Да, Мистер X сперва говорит "Да!" и поддерживает решение команды, а когда приходит время оценивать результат оказывается что ничего не сделано. Хотя есть оговорка, "Сделано" просто не то что было оговорено в команде и не то, что ожидается от нас.
В конечном итоге все это ведет к срыву сроков, потери репутации команды, недовольное руководство и компания теряет деньги и клиентов.
Что же не так и как делать правильно?
Вот список действенных советов:
1️⃣ Не нарушайте договоренности в команде
2️⃣ Если все-таки хотите изменить план, подготовьтесь и обсудите с командой
3️⃣ Не шумите, если считаете что команда идет в неправильном направлении. Подготовьтесь и конструктивно изложите ваше мнение
4️⃣ Прежде чем что-либо предлагать подумайте трижды
5️⃣ Помните, команда ровняется на лидера. Не можете убедить лидера, попытайтесь убедить всех остальных по отдельности и заручиться их поддержкой заблаговременно
6️⃣ Создавать правильные ожидания от ваших предложений. Все должны понимать, что вы предлагаете и какие будут результаты
7️⃣ Не используйте персональные оскорбления, если вам не нравится человек
По сути, всё это называется "Хорошие манеры и быть чуточку умнее" и казалось бы это знать должен каждый.
Если передвинуться в настоящее время, то обстановка уже наладилась и команда перформит (англ. - perform). На прошлой неделе состоялась первая демо-сессия, где мы получили зелёный свет на подготовку еще одной демо-сессии. Если вторая демо-сессия будет также успешной, то проект получит зеленый свет для перехода из MVP в состояние полноценного проекта.
🌟 А чтобы ты сделал для изменения командного план? Пиши в комментариях.
🌟 Пиши в комментариях свои мысли, если считаешь что данный список можно расширить.
Макс Добрынин