ООО «ИЛАДА» corporate blog
ERP-systems
CRM systems
Development Management
Comments 25
0
Хм, разве? Управление разработкой, agile — это всё же тема для менеджеров проектов и тимлидов. Пост очень даже в тему Хабра.
+3
Так вроде Мегамозг как раз для тем для менеджеров проектов и управления бизнесом. А впрочем я (да и не только я, видимо) совсем запутался уже что куда.
+1
Управление проектом, управление бизнесом и управление проектами разработки — это понятия, которые сильно отличаются по своей сути. Всё же управление разработкой — хаб Хабра, так что вроде всё логично.
+4
Зашел почитать про разработку ERP, CRM и ИТ инфраструктуры, а мне тут опять agile'ом мозг засирают.
-1
А что, agile не применим к разработке корпоративного софта? Или все методологии не применимы? По опыту вам скажу, ничего особенного в такой разработке нет, всё вполне по циклу: сбор требований, постоянная наработка функционала релиз за релизом, заморочки на том, чтобы GUI был всем понятен: от секретарши до гендира, интеграции с телефонией и 1С, выбор БД. С графовой БД под CRM не размахнёшься, поэтому выбор падает на стандартные реляционные: от Firebird до Oracle.

А вот ИТ-инфраструктуру разрабатывать как таковую нельзя, поскольку она состоит из элементов, среди которых есть ПО разного типа, каждый из которых разрабатывался по-своему.
+4
Agile — это сокращение расходов на разработку за счет значительного понижения качества разрабатываемого продукта. Именно поэтому государственные, военные (и игровые вроде Blizzard) компании выбирают классический «водопад», чтобы получить на выходе более высокое качество продукта для длительной эксплуатации, а не наколенное недоделанное *овно, слепленное из недоразвитых «супер» идей бизнес менеджмента.
+2
А ещё под водопадом хорошо деньги прятать и сосать из инвестора/заказчика — это самая трудоёмкая и косная модель, благодать: накручивай и накручивай суммы. А вот agile ориентирован на исполнение бюджета. Насчёт качества продукта — это при любой модели можно г**** сотворить. Хотя отчасти быстрая разработка способствует размножению костылей, есть такое.
+1
Вы перепутали — это agile позволяет накручивать ценник за разработку, т.к. разрабатывается неизвестно даже что, поэтому манагеры говорят заказчику «мы тут в прошлой итерации попробовали и… не выстрелило, давайте в следующей итерации попробуем вот-так...»
В случае водопада, создается качественная проектная документация, с подробным описанием функционала, архитекторы создают фреймворк для проекта, что позволяет довольно точно предсказать сроки разработки, т.к. все строится из заранее определенных стандартных блоков. Сроки в этом случае известны, ценник фиксированный в договоре.
0
Ага, знаем. К концу проекта, во время сдачи в эксплуатацию окажется, что ключевой пункт ТЗ не предусматривает один нюанс, и нужно очень дофига архитектуру переделывать. Но денег и времени на это нет, поэтому при помощи костылей и такой-то матери лепят имитацию нормальной работы, лишь бы тесты проходило. Исключений пока не встречал.

Что касается документации, фреймворка и сроков — это все можно и в обычных итерациях предусмотреть. Итерация не обязана быть одним днем, это может быть и месяц, и полгода-год. Сколько угодно примеров, когда проект несколько раз менял даже не фреймворк, а полностью весь стек технологий из-за того, что в выбранном ранее обнаруживался тупик и проще все переписать, чем городить карточные домики из костылей.
0
Насчет близзардов не знаю, а государственные и военные обычно не создают что-то принципиально новое и непонятное, а заказывают "то же самое, тысячу штук". И тогда полное планирование процессов себя оправдывает.
+2
Agile — модная забава руководителей, для которых главное — ввязаться в проект. Априори предполагающая для исполнителя неоднократные переделки за те-же деньги и в те-же сроки.
+3
Как мне кажется, agile/scrum к российским реалиям совершенно не подходит.

Во всех этих гибких методологиях заложена такая идея, что команда важнее продукта/результата. Т.е. если у вас есть команда которая может выполнять текущие задачи с некоторым успехом, то это намного важнее чем сможет ли она запилить продукт X. Т.к. сам продукт без команды мало что стоит. И это очень хорошо перекликается с ситуацией в кремниевой долине, где квалифицированный разработчик добавляет в среднем +1 млн. к капитализации компании при инвестиционной оценке ( http://blog.gust.com/10-rules-of-thumb-for-startup-investment-valuation/ )

В РФ совершенно другая ситуация — найти хорошего инвестора и сформировать бюджет намного-много сложнее чем найти разработчиков. Поэтому неприкосновенность бюджета и работа "на результат" важнее ситуации в команде, и порой здравого смысла. Шаг вправо-влево от поставленной задачи приравнивается к предательству. Массовые увольнения практикуются как в мелких конторах, так и в очень кру��ных. Даже если формально и заявляется что разработка идет по agile, то как правило это такой "русский agile" где решение начальника закон, а разбор беклога сводится в итоге к ежедневной торжественной порке.

Поэтому agile/scrum это не для РФ совершенно.
+2
найти хорошего инвестора и сформировать бюджет намного-много сложнее чем найти разработчиков

Ну если считать за разработчиков большую часть пользователей какого нить fl.ru, то да, найти их не проблема. Правильнее вашу мысль будет изложить (я считаю) так — в России нужно получить деньги на руки, а затем закрыть проект с помощью соплей и палок. В развитых странах такое не прокатит, ибо могут и засудить.
+2
Да, согласен, найти грамотного спеца в РФ намного сложнее чем в Калфорнии, но с инвестициями и финансированием все еще хуже.
+3
Методология тут совершенно ни при чем. Задача любой адекватной компании — это, в первую очередь, запилить продукт. Задача методологии сделать из рандомных людей команду с +- предсказуемой производительностью. Складываем второе и первое, и все счастливы.
Вы же говорите о низкой культуре управленческих кадров. Но это проблема не России, а конкретных людей и это везде так, поэтому многие и проваливаются безотносительно к географии и бюджетам.
+2
Мне кажется в РФ с культурой управления все довольно-таки хорошо. Проблема в том, что макроэкономическая реальность накладывает свои ограничения на пути развития бизнеса. И каким бы не было руководство демократичным на словах — на деле это мало отражается.

Вы ниже упомянули Грефа, про agile. Я тоже слышал это выступление, абсолютно согласен в этой части, что и организация должна перейти на Agile. Но структура организации обычно повторяет структуру финансовых потоков, тогда и финансовые потоки должны быть более горизонтальными и гибкими. Но это определенно не про страну в которой ставка рефинансирования 11% и за всю историю не опускалась ниже 8%.
+1
Не вижу связи, честно говоря. Наоборот, с той волатильностью, которая есть в экономике, я не представляю, как можно работать по-другому, чем не в Agile. Если у Вас есть такой опыт — расскажите!

с культурой управления все довольно-таки хорошо

Хм. Для меня отсутствие внятного планирования и оценки рисков, ужасные коммуникативные навыки, перманентный стресс, неспособность выстроить климат внутри команды, нетерпимость к ошибкам — это все плохая культура управления. А что для вас?
+2
Не вижу связи, честно говоря. Наоборот, с той волатильностью, которая есть в экономике, я не представляю, как можно работать по-другому, чем не в Agile. Если у Вас есть такой опыт — расскажите!

Допустим у вас есть agile-команда, которая работает на российского заказчика. В какой-то момент, заказчик движимый своими какими-то внутренними установками приходит и говорит — все, меня забодал ваш agile, теперь работаем как я скажу. В развитой экономике вы можете послать такого заказчика и покрыть расходы за счет кредитных средств (т.к. кредиты довольно дешевы). В РФ как правило, команды соглашаются на условия заказчика, т.к. найти какие-то средства или другого заказчика очень трудно.

Хм. Для меня отсутствие внятного планирования и оценки рисков, ужасные коммуникативные навыки, перманентный стресс, неспособность выстроить климат внутри команды, нетерпимость к ошибкам — это все плохая культура управления. А что для вас?

Я имел ввиду, что интеллектуальные и личные качества у российских тим лидов и управленцев в IT довольно хорошие. Но по сути они ни на что не влияют, т.к. все решения принимаются как правило теми кто ближе к финансам.
Конечно это тоже можно отнести к проблемам культуры управления, но скорее это все-таки проблема государства, института собственности и макроэкономических показателей. Т.к. это все приводит к тому, что собственники стараются владеть и управлять активами единолично. В итоге agile у нас приживается плохо.
+1
В этой методологии Agile интересен подход оценки выполненных работ в абстрактных единицах, а не в человеко-часах. У программистов есть определенные нюансы: программный код, обеспечивающий одну и туже функциональность может отличаться в размерах и человеко-часах в десятки, а то и сотни раз.
+2
Все-таки SCRUM в основном используется в проектах, над которыми работают небольшие команды из специалистов различного профиля как показано на картинке.

Картинка
image
+1
Вы, кстати, Грефа не услышали. Его основной посыл был в том, что вся организация, а не только ИТ, должна перейти на Agile.
Если уж вы стали писать про себя — сколько деплойментов в день вы делаете?
+1
Высказывания Германа Оскаровича на эту тему как-то странно интерпретируются, имхо.

Во-первых, основная мысль, которую он хотел донести до слушателей, заключалась в том, что в современных реалиях все большую роль в финансовой сфере начинают играть не банки, а ИТ-компании (такие как Google, Apple, Amazon и т.д.), которые залезают на этот рынок (Google Wallet, Apple Pay, Amazon Payments и т.д.), которым банки, и, в частности, Сбербанк, в ближайшей перспективе может начать уступать свои позиции, ЕСЛИ не сможет также оперативно предлагать новые продукты, модифицировать существующие продукты, исправлять неточности/ошибки и т.д.
Именно для этих целей Сбербанку (да и другим банкам) требуется новая парадигма управления изменениями, которая позволит возглавляемой им организации в обозримом будущем оставаться конкурентоспособной и прибыльной.

Во-вторых, мне непонятно, каким образом использование технологий компании GridGain (полагаю речь идет о ней), представляющих собой инструмент для ускорения обработки данных может сказаться на ускорении процессов внедрения изменений?
Имхо, централизация как раз большое подспорье во внедрении этих технологий, просто потому, что скорость обмена данными в центре централизованной (простите) системы — априори максимальна.

В-третьих, принципы управления компанией-разработчиком, имхо, очень сильно зависят от той категории клиентов, на которых она ориентирована.
Реалии, в которых существует Сбертех, автоматизирующий Сбербанк (имеется ввиду legacy, масштаб организации и все, что с этим связано), приводят к результату, который озвучил Герман Оскарович, т.е. к тому, что изменения в ИТ-системах вносятся достаточно неторопливо, т.к. производятся максимально осторожно, после многократного тестирования и проверок.
Увы, по другому нельзя, т.к. цена ошибки очень высока.
Вспомните хотя бы про >100 млн. карт, обслуживаемых Сбером, самую большую сеть отделений, банкоматов и пр.

Однако, учитывая кадровый состав Сбертеха :), я уверен, что этим людям вполне под силу выработать новые решения, которые позволят Сберу на равных конкурировать с Амазоном, Гуглом и т.д.
0
Есть мнение, что будущее в финансовой и банковской сфере за ИТ компаниями, которые будут иметь банковские лицензии. Вероятно, поэтому Греф говорит о Сбербанке, как о самой крупной ИТ компании РФ.
Я соглашусь с вашим мнением о том, что ускорение обработки данных вряд ли способствует ускорению внесения изменений в процессы Сбера.

Здесь нужна другая система управления процессами, включая процессы исследования новых направлений оказания банковских услуг, и процессы управления проектами новых решений, и бизнес процессы создания, тестирования и установки версий действующего ПО, и процессы технической поддержки пользователей, и процессы управления взаимоотношениями с клиентами. Возможно, им могло бы быть полезно наше решение Рули24 Управление процессами
0
За 2015г было создано около 200 версий различных модулей ПО и сделано более 2000 установок на наши сервера и сервера клиентов. Всего сделано боле 10 000 изменений.
Only those users with full accounts are able to leave comments., please.