Комментарии 25
Мегамозг, не?
Зашел почитать про разработку ERP, CRM и ИТ инфраструктуры, а мне тут опять agile'ом мозг засирают.
А что, agile не применим к разработке корпоративного софта? Или все методологии не применимы? По опыту вам скажу, ничего особенного в такой разработке нет, всё вполне по циклу: сбор требований, постоянная наработка функционала релиз за релизом, заморочки на том, чтобы GUI был всем понятен: от секретарши до гендира, интеграции с телефонией и 1С, выбор БД. С графовой БД под CRM не размахнёшься, поэтому выбор падает на стандартные реляционные: от Firebird до Oracle.
А вот ИТ-инфраструктуру разрабатывать как таковую нельзя, поскольку она состоит из элементов, среди которых есть ПО разного типа, каждый из которых разрабатывался по-своему.
А вот ИТ-инфраструктуру разрабатывать как таковую нельзя, поскольку она состоит из элементов, среди которых есть ПО разного типа, каждый из которых разрабатывался по-своему.
Agile — это сокращение расходов на разработку за счет значительного понижения качества разрабатываемого продукта. Именно поэтому государственные, военные (и игровые вроде Blizzard) компании выбирают классический «водопад», чтобы получить на выходе более высокое качество продукта для длительной эксплуатации, а не наколенное недоделанное *овно, слепленное из недоразвитых «супер» идей бизнес менеджмента.
А ещё под водопадом хорошо деньги прятать и сосать из инвестора/заказчика — это самая трудоёмкая и косная модель, благодать: накручивай и накручивай суммы. А вот agile ориентирован на исполнение бюджета. Насчёт качества продукта — это при любой модели можно г**** сотворить. Хотя отчасти быстрая разработка способствует размножению костылей, есть такое.
Вы перепутали — это agile позволяет накручивать ценник за разработку, т.к. разрабатывается неизвестно даже что, поэтому манагеры говорят заказчику «мы тут в прошлой итерации попробовали и… не выстрелило, давайте в следующей итерации попробуем вот-так...»
В случае водопада, создается качественная проектная документация, с подробным описанием функционала, архитекторы создают фреймворк для проекта, что позволяет довольно точно предсказать сроки разработки, т.к. все строится из заранее определенных стандартных блоков. Сроки в этом случае известны, ценник фиксированный в договоре.
В случае водопада, создается качественная проектная документация, с подробным описанием функционала, архитекторы создают фреймворк для проекта, что позволяет довольно точно предсказать сроки разработки, т.к. все строится из заранее определенных стандартных блоков. Сроки в этом случае известны, ценник фиксированный в договоре.
Ага, знаем. К концу проекта, во время сдачи в эксплуатацию окажется, что ключевой пункт ТЗ не предусматривает один нюанс, и нужно очень дофига архитектуру переделывать. Но денег и времени на это нет, поэтому при помощи костылей и такой-то матери лепят имитацию нормальной работы, лишь бы тесты проходило. Исключений пока не встречал.
Что касается документации, фреймворка и сроков — это все можно и в обычных итерациях предусмотреть. Итерация не обязана быть одним днем, это может быть и месяц, и полгода-год. Сколько угодно примеров, когда проект несколько раз менял даже не фреймворк, а полностью весь стек технологий из-за того, что в выбранном ранее обнаруживался тупик и проще все переписать, чем городить карточные домики из костылей.
Что касается документации, фреймворка и сроков — это все можно и в обычных итерациях предусмотреть. Итерация не обязана быть одним днем, это может быть и месяц, и полгода-год. Сколько угодно примеров, когда проект несколько раз менял даже не фреймворк, а полностью весь стек технологий из-за того, что в выбранном ранее обнаруживался тупик и проще все переписать, чем городить карточные домики из костылей.
Насчет близзардов не знаю, а государственные и военные обычно не создают что-то принципиально новое и непонятное, а заказывают "то же самое, тысячу штук". И тогда полное планирование процессов себя оправдывает.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
найти хорошего инвестора и сформировать бюджет намного-много сложнее чем найти разработчиков
Ну если считать за разработчиков большую часть пользователей какого нить fl.ru, то да, найти их не проблема. Правильнее вашу мысль будет изложить (я считаю) так — в России нужно получить деньги на руки, а затем закрыть проект с помощью соплей и палок. В развитых странах такое не прокатит, ибо могут и засудить.
Методология тут совершенно ни при чем. Задача любой адекватной компании — это, в первую очередь, запилить продукт. Задача методологии сделать из рандомных людей команду с +- предсказуемой производительностью. Складываем второе и первое, и все счастливы.
Вы же говорите о низкой культуре управленческих кадров. Но это проблема не России, а конкретных людей и это везде так, поэтому многие и проваливаются безотносительно к географии и бюджетам.
Вы же говорите о низкой культуре управленческих кадров. Но это проблема не России, а конкретных людей и это везде так, поэтому многие и проваливаются безотносительно к географии и бюджетам.
НЛО прилетело и опубликовало эту надпись здесь
Не вижу связи, честно говоря. Наоборот, с той волатильностью, которая есть в экономике, я не представляю, как можно работать по-другому, чем не в Agile. Если у Вас есть такой опыт — расскажите!
Хм. Для меня отсутствие внятного планирования и оценки рисков, ужасные коммуникативные навыки, перманентный стресс, неспособность выстроить климат внутри команды, нетерпимость к ошибкам — это все плохая культура управления. А что для вас?
с культурой управления все довольно-таки хорошо
Хм. Для меня отсутствие внятного планирования и оценки рисков, ужасные коммуникативные навыки, перманентный стресс, неспособность выстроить климат внутри команды, нетерпимость к ошибкам — это все плохая культура управления. А что для вас?
В этой методологии Agile интересен подход оценки выполненных работ в абстрактных единицах, а не в человеко-часах. У программистов есть определенные нюансы: программный код, обеспечивающий одну и туже функциональность может отличаться в размерах и человеко-часах в десятки, а то и сотни раз.
Все-таки SCRUM в основном используется в проектах, над которыми работают небольшие команды из специалистов различного профиля как показано на картинке.
Картинка
Вы, кстати, Грефа не услышали. Его основной посыл был в том, что вся организация, а не только ИТ, должна перейти на Agile.
Если уж вы стали писать про себя — сколько деплойментов в день вы делаете?
Если уж вы стали писать про себя — сколько деплойментов в день вы делаете?
Высказывания Германа Оскаровича на эту тему как-то странно интерпретируются, имхо.
Во-первых, основная мысль, которую он хотел донести до слушателей, заключалась в том, что в современных реалиях все большую роль в финансовой сфере начинают играть не банки, а ИТ-компании (такие как Google, Apple, Amazon и т.д.), которые залезают на этот рынок (Google Wallet, Apple Pay, Amazon Payments и т.д.), которым банки, и, в частности, Сбербанк, в ближайшей перспективе может начать уступать свои позиции, ЕСЛИ не сможет также оперативно предлагать новые продукты, модифицировать существующие продукты, исправлять неточности/ошибки и т.д.
Именно для этих целей Сбербанку (да и другим банкам) требуется новая парадигма управления изменениями, которая позволит возглавляемой им организации в обозримом будущем оставаться конкурентоспособной и прибыльной.
Во-вторых, мне непонятно, каким образом использование технологий компании GridGain (полагаю речь идет о ней), представляющих собой инструмент для ускорения обработки данных может сказаться на ускорении процессов внедрения изменений?
Имхо, централизация как раз большое подспорье во внедрении этих технологий, просто потому, что скорость обмена данными в центре централизованной (простите) системы — априори максимальна.
В-третьих, принципы управления компанией-разработчиком, имхо, очень сильно зависят от той категории клиентов, на которых она ориентирована.
Реалии, в которых существует Сбертех, автоматизирующий Сбербанк (имеется ввиду legacy, масштаб организации и все, что с этим связано), приводят к результату, который озвучил Герман Оскарович, т.е. к тому, что изменения в ИТ-системах вносятся достаточно неторопливо, т.к. производятся максимально осторожно, после многократного тестирования и проверок.
Увы, по другому нельзя, т.к. цена ошибки очень высока.
Вспомните хотя бы про >100 млн. карт, обслуживаемых Сбером, самую большую сеть отделений, банкоматов и пр.
Однако, учитывая кадровый состав Сбертеха :), я уверен, что этим людям вполне под силу выработать новые решения, которые позволят Сберу на равных конкурировать с Амазоном, Гуглом и т.д.
Во-первых, основная мысль, которую он хотел донести до слушателей, заключалась в том, что в современных реалиях все большую роль в финансовой сфере начинают играть не банки, а ИТ-компании (такие как Google, Apple, Amazon и т.д.), которые залезают на этот рынок (Google Wallet, Apple Pay, Amazon Payments и т.д.), которым банки, и, в частности, Сбербанк, в ближайшей перспективе может начать уступать свои позиции, ЕСЛИ не сможет также оперативно предлагать новые продукты, модифицировать существующие продукты, исправлять неточности/ошибки и т.д.
Именно для этих целей Сбербанку (да и другим банкам) требуется новая парадигма управления изменениями, которая позволит возглавляемой им организации в обозримом будущем оставаться конкурентоспособной и прибыльной.
Во-вторых, мне непонятно, каким образом использование технологий компании GridGain (полагаю речь идет о ней), представляющих собой инструмент для ускорения обработки данных может сказаться на ускорении процессов внедрения изменений?
Имхо, централизация как раз большое подспорье во внедрении этих технологий, просто потому, что скорость обмена данными в центре централизованной (простите) системы — априори максимальна.
В-третьих, принципы управления компанией-разработчиком, имхо, очень сильно зависят от той категории клиентов, на которых она ориентирована.
Реалии, в которых существует Сбертех, автоматизирующий Сбербанк (имеется ввиду legacy, масштаб организации и все, что с этим связано), приводят к результату, который озвучил Герман Оскарович, т.е. к тому, что изменения в ИТ-системах вносятся достаточно неторопливо, т.к. производятся максимально осторожно, после многократного тестирования и проверок.
Увы, по другому нельзя, т.к. цена ошибки очень высока.
Вспомните хотя бы про >100 млн. карт, обслуживаемых Сбером, самую большую сеть отделений, банкоматов и пр.
Однако, учитывая кадровый состав Сбертеха :), я уверен, что этим людям вполне под силу выработать новые решения, которые позволят Сберу на равных конкурировать с Амазоном, Гуглом и т.д.
Есть мнение, что будущее в финансовой и банковской сфере за ИТ компаниями, которые будут иметь банковские лицензии. Вероятно, поэтому Греф говорит о Сбербанке, как о самой крупной ИТ компании РФ.
Я соглашусь с вашим мнением о том, что ускорение обработки данных вряд ли способствует ускорению внесения изменений в процессы Сбера.
Здесь нужна другая система управления процессами, включая процессы исследования новых направлений оказания банковских услуг, и процессы управления проектами новых решений, и бизнес процессы создания, тестирования и установки версий действующего ПО, и процессы технической поддержки пользователей, и процессы управления взаимоотношениями с клиентами. Возможно, им могло бы быть полезно наше решение Рули24 Управление процессами
Я соглашусь с вашим мнением о том, что ускорение обработки данных вряд ли способствует ускорению внесения изменений в процессы Сбера.
Здесь нужна другая система управления процессами, включая процессы исследования новых направлений оказания банковских услуг, и процессы управления проектами новых решений, и бизнес процессы создания, тестирования и установки версий действующего ПО, и процессы технической поддержки пользователей, и процессы управления взаимоотношениями с клиентами. Возможно, им могло бы быть полезно наше решение Рули24 Управление процессами
За 2015г было создано около 200 версий различных модулей ПО и сделано более 2000 установок на наши сервера и сервера клиентов. Всего сделано боле 10 000 изменений.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Управление компанией-разработчиком: оно вам надо?