Как доказать моему стейкхолдеру и менеджеру, что мое программное обеспечение работает? [закрытый]

Я являюсь частью команды, работающей над крупным проектом для государственного заказчика. Первый модуль фазы 1 был огромной катастрофой, команда была неуправляемой, не было команды QA, и разработчики не были мотивированы работать лучше. Вместо этого менеджер продолжал кричать и вычитал заработную плату для людей, которые не работали сверхурочно!!

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

Итак, каково же было решение:

Первым делом отделили руководство от программистов, и поставили дружный коллектив руководителем. Во-вторых, получить квалифицированную команду QA. В первые несколько недель жуки были в 100-х годах. В-третьих, поставьте 2-3 разработчика в качестве команды поддержки, там ответственность заключается не в том, чтобы делать какие-то новые задачи, а просто исправлять ошибки, работать непосредственно с QA. В-четвертых, мотивируйте ребят, иногда речь идет не о деньгах или дополнительных каникулах, иногда хорошее слово будет идеальный. Небольшой пример: проработав 3 дня подряд почти по 15 часов в день, руководитель группы сделал замечание менеджеру. Через два дня я получил письмо от генерального директора, в котором он поблагодарил меня за мои усилия и дал мне 2 дня отпуска.

Мы скоро поставим 4-й модуль системы, и как один из команды поддержки я мог бы сказать, что его по крайней мере 95% ошибка свободна. Что является огромным скачком от наших первых модулей.

Сегодня у нас есть мощная команда разработчиков, квалифицированный QA и эксперт баг фиксажи.

Извините за длинную историю, но именно так наша команда (в течение 4 месяцев) доказала менеджеру и клиенту, что мы надежны и просто нуждаемся в правильной среде.

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

Такова роль U ser A cceptance T esting: показать, что достигнут приемлемый уровень полезности.

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

К сожалению, совершенно невозможно "доказать", что ваше программное обеспечение работает без ошибок (реклама windows xp всегда раздражала меня объявляя "самую безопасную версию windows когда-либо", это невозможно доказать при выпуске). Это зависит от руководства, чтобы настроить и внедрить процесс контроля качества и установить метрики относительно того, как на самом деле выглядит готовый продукт и какой уровень ошибок или неожиданного поведения допустим в финальном выпуске.

Тем не менее, если вы-небольшая команда и устанавливаете свою собственную политику контроля качества с небольшим вкладом от руководства, я думаю, что было бы выгодно написать базовый процесс контроля качества и иметь руководство подписывает его. Для наших веб-приложений мы в настоящее время поддерживаем 4 браузера-и руководство знает об этом-поэтому, когда приложение ломается в каком-то непонятном портативном браузере, все ясно понимают, что это не то, что мы разработали приложение для поддержки. Это также обеспечивает хорошие рычаги для найма дополнительных ресурсов разработки или тестирования, когда руководство решает, что оно хочет начать тестирование для x.

Как однажды сказал Билли Джоэл: "это всегда было вопросом доверия."

Вы должны понимать, что разработка программного обеспечения-это "черная магия" для всех, кроме тех, кто пишет программное обеспечение. Это не очевидно (на самом деле, довольно противоречиво) для остальной части вашей компании, что многие из ваших инициатив приводят к повышению качества и снижению риска запуска с течением времени и/или бюджета. Ключ заключается в построении доверительных, уважительных отношений между развитием и другими частями общества. бизнес. Как вы строите это доверие? Ну, это одна из тех проблем с обидчивыми людьми... вам нужно будет немного поэкспериментировать. Я часто использую следующие инструменты:

1. видимость процесса - Убедитесь, что все знают, что вы делаете и как продвигаются дела. Кроме того, убедитесь, что каждый может видеть влияние и изменения, которые происходят во время разработки.
2. укажите на маленькие победы - чтобы укрепить доверие, укажите, когда все пошло именно так, как ты все спланировал. Попытайтесь найти ситуации, в которых вы должны были принять решение и использовать термин "смягчение риска" с вашим руководством.
3. не сказать, "я сказал вам так.- Предположим, вы сказали руководству, что вам нужно 2 месяца, чтобы выполнить какую-то задачу, и они сказали: "Ну, у вас есть только три недели."Результат вряд ли будет хорошим (при условии, что ваша оценка точна). Поставьте руководство в известность о проблеме и задокументируйте все, что вам нужно было сделать, чтобы попытаться решить эту проблему. крайний срок. Когда качество оказывается плохим, вы можете работать над проблемами, с которыми вы столкнулись (и записали) в профессиональной манере, а не показывать пальцем и говорить: "Я же вам говорил."

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

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