Специфика деятельности разработчика банковских продуктов состоит в том, что он занимается переводом требования бизнеса на язык всех остальных подразделений банка. Постоянный контакт с юристами, рисками, планировщиками и программистами порой реально может свести с ума. У каждого подразделения свои цели, своя мотивация, свои правила и инструкции, своя манера общения. И если с IT работать - одно удовольствие, то со всеми остальными - полная противоположность.
Чтобы внедрить что-то новое в банке нужно пройти все круги ада, а именно получить положительное заключение юриста, рассчитать все доходы и расходы для экономистов, привести список возможных рисков и чем их можно минимизировать. И все бы хорошо, но я не юрист, не рисковик и не экономист... Да, я знаю определнные акты, могу провести STEP/SWOT-анализ и посмотреть риски и способы их минимизации, посчитать предоположительные доходы и расходы. Но сделаю это не так качественно, как могли бы сделать квалифицированные в каждой конкретной области специалисты.
С точки зрения менеджмента - это ошибка, когда одним "универсальным солдатом" тратится куча времени на изучение законодательства, подсчет рисков и доходов/расходов. Затем тратится время юристами, рисковиками, экономистами на проверку этих данных. А это время можно было урезать в два раза!
Кинуть идею, собраться и распределить задания подразделениям на проработку всех вопросов (юридических, рисковых, экономических) и прийти к итоговому решению. Потом уже должна идти разработка продукта, регламентирование и внедрение.
Чем мне нравится работа с программистами? Они знают свое дело и ни на кого ничего не перекладывают, им просто не на кого это переложить. Они делают то, что скажет им бизнес, делают это так, как скажет им бизнес. А значит для того, чтобы все работало "как надо", главное - наладить контакт с IT-подразделениями. Поработав в трех банках я понял, что самое простое для обеих сторон - не столько подробное техническое задание, сколько правильный подход и понятный ход мыслей. Хотя ТЗ тоже важно, как говориться: "Нету ТЗ - давай, до свиданья!" ТЗ является началом разговора, как будто говорит "привет!" IT-подразделению, задает тон и является позвоночником разработки продукта. Цель тех. задания: донести ход своих мыслей, желание бизнеса, его видение в голову программиста, показать структуру продукта, какие-то мелочи. Но ни в коем случае разработчик продукта не должен заканчивать свой контакт с IT отправкой ТЗ. Контакт с IT должен продолжаться на каждой ступени разработки продукта. Только тогда бизнес получит в итоге именно то, что хотел получить.
Одно плохо в общении с программистами - они порой переходят на свой язык. Многим он напоминает язык жестов... Ребята, покажите на пальцах, а я скажу, круто или что-то не то! И они показывают и все понятно и просто... И не надо искать законы, пытаться оценить риски, посчитать дебет с кредитом...
На каждую задачу должен быть свой специалист, который собаку съел в этом вопросе. Тогда продукт получится таким, каким задумывался, а срок внедрения не превысит плановый.
Чтобы внедрить что-то новое в банке нужно пройти все круги ада, а именно получить положительное заключение юриста, рассчитать все доходы и расходы для экономистов, привести список возможных рисков и чем их можно минимизировать. И все бы хорошо, но я не юрист, не рисковик и не экономист... Да, я знаю определнные акты, могу провести STEP/SWOT-анализ и посмотреть риски и способы их минимизации, посчитать предоположительные доходы и расходы. Но сделаю это не так качественно, как могли бы сделать квалифицированные в каждой конкретной области специалисты.
С точки зрения менеджмента - это ошибка, когда одним "универсальным солдатом" тратится куча времени на изучение законодательства, подсчет рисков и доходов/расходов. Затем тратится время юристами, рисковиками, экономистами на проверку этих данных. А это время можно было урезать в два раза!
Кинуть идею, собраться и распределить задания подразделениям на проработку всех вопросов (юридических, рисковых, экономических) и прийти к итоговому решению. Потом уже должна идти разработка продукта, регламентирование и внедрение.
Чем мне нравится работа с программистами? Они знают свое дело и ни на кого ничего не перекладывают, им просто не на кого это переложить. Они делают то, что скажет им бизнес, делают это так, как скажет им бизнес. А значит для того, чтобы все работало "как надо", главное - наладить контакт с IT-подразделениями. Поработав в трех банках я понял, что самое простое для обеих сторон - не столько подробное техническое задание, сколько правильный подход и понятный ход мыслей. Хотя ТЗ тоже важно, как говориться: "Нету ТЗ - давай, до свиданья!" ТЗ является началом разговора, как будто говорит "привет!" IT-подразделению, задает тон и является позвоночником разработки продукта. Цель тех. задания: донести ход своих мыслей, желание бизнеса, его видение в голову программиста, показать структуру продукта, какие-то мелочи. Но ни в коем случае разработчик продукта не должен заканчивать свой контакт с IT отправкой ТЗ. Контакт с IT должен продолжаться на каждой ступени разработки продукта. Только тогда бизнес получит в итоге именно то, что хотел получить.
Одно плохо в общении с программистами - они порой переходят на свой язык. Многим он напоминает язык жестов... Ребята, покажите на пальцах, а я скажу, круто или что-то не то! И они показывают и все понятно и просто... И не надо искать законы, пытаться оценить риски, посчитать дебет с кредитом...
На каждую задачу должен быть свой специалист, который собаку съел в этом вопросе. Тогда продукт получится таким, каким задумывался, а срок внедрения не превысит плановый.
Комментариев нет:
Отправить комментарий