Управление качеством в сфере ИТ - адаптация качества к стадии развития организации - Unity

1. Представьте себе, что коллега спрашивает вас на начальном этапе анализа, какого качества проекта вы...
2. Управление качеством и модель развития инновационного бизнеса
3. Обнаружение клиента
4. Проверка клиентов
5. Этап развития клиента и качество ИТ-решений
6. Качество во время масштабирования бизнеса
7. Всегда ли стоит начинать с более низкого качества?

Представьте себе, что коллега спрашивает вас на начальном этапе анализа, какого качества проекта вы ожидаете. Скорее всего, в первом рефлексе вы ответите: самый высокий! И на самом деле никто не удивится. Однако это лучший ответ? При покупке торта это должен быть самый сладкий и самый быстрый автомобиль?

Из этой статьи вы узнаете:

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

Что такое качество?

Классические мыслители уже интересовались темой качества. Платон писал: «качество (греческие poiotes, латинские qualitas) - это степень совершенства»

Платон, Источник: Википедия

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

Но как превратить управление качеством в практику выполнения ИТ-проектов?

Управление качеством и модель развития инновационного бизнеса

Мир, в котором мы живем, становится все более изменчивым, сложным и полным неопределенности. Многие эксперты называют его VUCA World (волатильность, неопределенность, сложность и неоднозначность). Это заставляет использовать высокоадаптивные методологии, то есть гибкие методологии. В случае ИТ-проекта есть несколько методов, основанных на гибкости, таких как набор, который мы используем AgilePM и Scrum ,

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

Для тех, кто хочет подробно ознакомиться с этими методами, рекомендую книгу «Руководство по запуску». Построение крупной компании шаг за шагом »Стивом Бланком, Бобом Дорфом или« Разработка Lean Customer »Синди Альварес.

В нескольких словах - в концепции развития клиентов речь идет о быстрой проверке гипотез рынка и постепенной коррекции и развитии всего, что связано с продуктом / проектом (сотрудники Agile, безусловно, звучат знакомо;))

Развитие клиентов, Источник: Custdev.com

Обнаружение клиента

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

Проверка клиентов

Проверка часто приводит к изменениям (стержню), которые необходимо сделать быстро и дешево. Только когда мы действительно проверяем, что наш продукт подходит для выбранных клиентов, мы разрабатываем окончательную бизнес-модель (например, в соответствии с моделью бизнес-модели Canvas, описанной Александром Остервальдером) вместе с планом продаж и маркетинга, а затем мы начинаем выходить с продуктом на рынок. ,

Следующие два этапа - масштабирование бизнеса. Таким образом, Customer Creation, то есть завоевывает достаточно клиентов, чтобы получить место на рынке вне группы «ранних последователей». Когда мы готовы заявить, что деятельность по продажам эффективна, мы создаем организацию, которая допускает повторную доставку продуктов, то есть мы достигаем этапа создания компании.

Этап развития клиента и качество ИТ-решений

Но как это происходит при создании кода продукта?

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

Таким образом, на данном этапе качество не имеет значения, но самая дешевая реализация MVP. Это может привести к тому, что код будет «нестабильным», только один человек действительно будет его знать, будет нестабильным и неэффективным, не сможет пройти все тесты .... Одним словом, он будет полон технологического долга, автору будет стыдно, что он сделал что-то подобное, и в SonarQube все будет «светиться» красным, почти крича, что программное обеспечение бесполезно.

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

Многие опытные разработчики избегают такого подхода, потому что у них есть плохой опыт из прошлого - «мы сделали быстрый и грязный проект по требованию бизнеса, а затем они сказали нам оставить его». Я сам видел такие ситуации, когда было решено, что проект работает функционально, поэтому его легко реализовать, и тогда на этапе разработки возникли разочарования и взаимные претензии. Но с общим пониманием целей мы можем сделать прототип. Конечно, осознание того, что вступление в фазу масштабирования означает фактическое создание системы с нуля, без добавления новых функциональных возможностей для пользователя. И это часто лучшее решение.

Развитие клиентов и Agile

Если мы считаем, что система будет работать, мы можем сразу же рискнуть создать «высококачественный» продукт, потому что гипотетическая сумма затрат на создание хорошей системы ниже, чем постепенное улучшение. Просто в ИТ производство для инвентаризации часто не работает, потому что мир VUCA полон изменений и на практике лучше расширить функциональность на практике, минимизируя стоимость отсутствующих идей.

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

Качество во время масштабирования бизнеса

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

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

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

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

Изменение доли затрат на ИТ в общей стоимости инновационного проекта и проблем, возникающих на отдельных этапах

Всегда ли стоит начинать с более низкого качества?

Таким образом, мы начинаем с более низкого качества, когда это действительно инновационный проект, и мы не уверены в его успехе. Однако, когда мы, например, автоматизируем процесс, который уже существовал, или заменяем старую неэффективную систему (унаследованную систему) на новую, тогда необходимо немедленно использовать высокое качество, потому что мы работаем сразу на этапе создания компании.

Похожие

Комментарии