Цитата:
Сообщение от
skad
Какие книжки читать, кроме бухучета
? Какие основополагающие процессы следует изучить в первую очередь? Какие основные этапы освоения и в каком порядке можете выделить? Стою в тупике, а начать с чего-то нужно.
Из поставленных вопросов сразу следует глобальная ошибка. Разработчик всегда изучает новое по книжкам. А консультант - в первую очередь по общению. А книжки - лишь приложение к общению.
Самый простой способ стать консалтом - посидеть на поддержке. Сначала будут ответы типа "Ваш вопрос понял - сейчас посмотрю и Вам перезвоню", а затем уже бодренько так будете знать ответы на вопросы.
В этом случае - книжка / РП (руководство пользователя) / ПИ (пользовательская инструкция) будет в помощь при решении вопросов.
Следующий этап (после того, как будет освоена поддержка) - это написание РП по существующему функционалу. Уже будет понятно - что следует осветить пользователям. Да и уже сами поймете, что пользователь ощущает при чтении РП. Здесь должна будет прийти в голову главная мысль - что 5-минутное добавление галки в интерфейс влечет за собой обновление кучи РП и скриншотов.
Следующий этап (Вы уже научились формулировать свои мысли и представлять себе образ мышления пользователя) - написание ФД (функциональный дизайн) или заданий на разработку. И их согласование. Здесь должно прийти понимание, как нужно писать документ, чтобы он с одной стороны был понятен разработчику, а с другой стороны - был понятен заказчику для согласования. Попутно тренируются навыки общения с пользователями.
Все. После этого - Вы консалт. Вы умеете общаться с народом и осуществлять суппорт. Вы умеете писать документы на языке пользователя. Вы умеете транслировать хотелки пользователя в задания на разработку.
Дальше останется совершенствовать свои знания, путем изучения документации (но Вы уже знаете бизнес-процессы) и пониманием - что можно сделать без программирования (штатным функционалом), а что нужно кодить. Соответственно - при увеличении багажа знаний - увеличивается и ценность консалта, который знает как тот или иной бизнес-процесс оптимальнее переложить в систему.