Как убедить команду, что другие части разработки программного обеспечения важны?

Question

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

1. Автоматизированные модульные тесты и интеграционные тесты в сравнении с их ручным функциональным тестированием.
2. Использование генераторов кода и сценариев для повторяющихся задач.

Я иногда встречал сопротивление. Вот некоторые из причин:

1. Они говорят, что так мы здесь поступаем. Наша система работает, и нет необходимости добавлять в наш процесс.
2. Они заняты, заняты. Они говорят, что их работа заключается в том, чтобы получить от нас проекты, а наша задача - доставить их им к их удовлетворению. Они удовлетворены, когда это ручная система, повторяющаяся, но вовремя.
3. Они очень консервативны в отношении генераторов кода. Я дал им оценку, что для первого проекта потребуется значительное время, чтобы использовать это и время для обучения моих товарищей по команде, так как этот подход является относительно новым для них. Затраты на первый проект для них затмевают выгоду в долгосрочной перспективе, но я объяснил удобство для нас, разработчиков, но они всегда застряли, чтобы делать вещи по-старому.

Какова будет ваша стратегия для этого?

Answer 1

Подождите, пока проблема не появится , а затем сделает ваш ход .

Answer 2

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

Если вы можете подкрепить свои претензии каким-либо временем, проведенным / сохраненными данными, вы станете победителем. Другое дело, чтобы постепенно завоевать себе репутацию, согласившись, что изменения будут осуществляться поэтапно. Внесите простое изменение в небольшой фрагмент проекта и докажите, что это имело значение для них. Затем разверните его немного дальше и перейдите к следующему этапу, такому как модульное тестирование или генерация кода. Со временем все сработает.

Я не верю, что вы не можете заставить людей читать книги, они откладывают их и думают, что вы противны. Лучше всего добиться небольших результатов и использовать их в качестве трамплина, чтобы им было позволено стремиться к более высоким целям, поскольку люди понимают, что, возможно, являются более совершенными способами сделать что-то.

Если вы действительно увлечены этим, вы всегда можете потратить немного своего времени и подготовить небольшую демонстрацию (30 минут), которая покажет им, как быстро вы можете создать крошечное приложение без кода gen, а затем то же самое приложение с парой битов, сгенерированных кодом. Доказательство пудинга в еде.

Answer 3

Проще просить прощения, чем получать разрешение.

Нет объективных измерений стиля возврата инвестиций для "улучшения" процесса разработки программного обеспечения. Разработка программного обеспечения по своей сути сложна - это захват знаний - там должны быть неизвестные. Если бы все было известно, у вас уже было бы программное обеспечение под рукой.

Следовательно, вы никогда не сможете убедить менеджера в чем-либо заранее.

Вы можете только продемонстрировать, что вы можете сделать что-то лучше, дешевле или быстрее. Когда они спрашивают, в чем секрет вашей производительности, вы можете показать им свои инструменты, метод или подход.

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

Поскольку они не хотят расстраивать свой график «делай все вручную», вкладывая средства в свои инструменты, вы должны строить свои инструменты поэтапно, по одному проекту за раз.

Answer 4

Я думаю, что единственный способ убедить кого-то в чем-то - это раскрыть преимущества, которые оно дает.

Answer 5

«С улыбкой и пистолетом можно продвинуться дальше, чем с улыбкой».
- Аль Капоне

Шучу, но это первое, что приходит мне в голову :)

Пистолет - это метафора (дух), как для ошибки, которую кто-то потратил несколько дней, выясняя, что с хорошим процессом он хорошо тратит более увлекательным образом.