«Дело мастера боится» — русская народная поговорка.
Заказчику повезло с Team Lead-ом.
Им найден способ как практически бескровно начать «апгрейдить» текущее ИТ-решение.
Правда, этот подвиг скорей всего останется не замеченным Заказчиком, но я вот для себя добавил Александра в «избранных» хабрачан, если мне или кому-то из моих друзей понадобится Мастер.
Никогда вообще не встречал тех проблем, что вы описали, хотя постоянно о них слышу… исключительно от тех, кто работает с заказчиками из рф.
Возможно это особенность нашей страны, когда крупная компания покупает платформу от западного вендора и ваяет на её основе систему под собственные нужды, изменив её так, что ты уже не можешь обновится до следующей выпущенной версии от вендора.
В нашем случае это была Pivotal CRM и покупалась в том момент, когда система входила в лидеры квадранта Gartner. Нас оправдывает только то, что лучших практик тогда не было.
Система создавалась для развития ипотечного рынка.
Ребята ездили в Америку изучать ИТ-системы и опыт Freddie Mac и Fannie Mae.
После этого было принято решение делать своё.
Система ежегодно переваривает ипотечных закладных на 60 млрд. рублей.
Выглядит с одной стороны много, но уже с масштабами Сбербанка не сравнить.
Его ИС переваривают ипотечных закладных на 661 млрд. рублей.
Два момента:
Когда мы этот снежный ком толкнули, мы не думали о том, что нам это понадобится.
А когда он нас накрыл, не было необходимой квалификации, чтобы этот вариант реализовать. Тогда он даже не пришёл в голову, насколько смогли «подтянуть себя за волосы», из того места где сидели, настолько подтянули.
А мне вот это не нравится — некрасиво. Тут я хочу вместо обычной кнопки красную и круглую. А в таком то случае, чтоб сообщение пользователю было «ололо», а не «трололо» и т.п.
Мы лечили это следующим образом:
Описание выполнения бизнес-операций сопровождалось картинками, где уже на старте было видно как будут выглядеть кнопочки, где круглые, а где красненькие. Что в ответ на их нажатие появится.
Мы настраивали Заказчиков минимум на три итерации. Первая — минимально работающее ИТ-решение решающее бизнес-задачу. Вторая — удобно и красиво. Третья — чтобы быстро работало.
Заказчик подписывал первую часть ТЗ и проверял в соответствии с ней, всё что не вошло в ТЗ, это дополнительное требование. Дополнительные требования оплачиваются за счёт Заказчика. При этом главный критерий приемки — то, что созданный ИТ-продукт решает бизнес-задачу ради которой задумывался. Система выдаёт целевой бизнес-результат, указанный в ТЗ.
Знаю, что некоторые ребята не просто картинки рисуют, а создают буквально работающее решение, которое можно «покликать». Делают с помощью Axure. Почитать и посмотреть можно здесь.
А вот если один продукт разобьёте на кучу мелких, то всё станет гораздо проще.
Мы так и поступили, вместо того, чтобы пытаться остаться в одном, Первом ТЗ, мы создали 300.
Не за один день, но подход был выбран именно такой.
Не факт, что их нужно было 300, но это материал для «рефакторинга» ТЗ.
Если 40 ТЗ описывают одну функциональную область и каждое из них про свою процедуру, есть повод задуматься про структурирование информации.
Сейчас это проблема решена на уровне меток / тегов с названиями бизнес-процессов и бизнес-процедур, указываемых к каждому ТЗ.
В поисках идеального тз, вы не получите не продукта, ни тз.
Вторая статья в списке для чтения на Хабре по теме как раз про это.
Полное отсутствие ТЗ порождает Diff(-erence) между тем что сделано и ожиданиями Заказчика.
ТЗ эту разницу позволяет сократить. Что включать в ТЗ это уже предмет изучения шишек на лбу команды.
Если Заказчик не зрелый в области проектирования своих собственных бизнес-процессов, то с ним точно надо описывать Бизнес-процесс с применением ИС. Это точно лучше, чем множество итераций/спринтов, и через них приходить с ним к тому процессу который будет ему удобен и более эффективен в сравнении с тем, что у него был до этого. Будет и быстрее по времени и ресурсов «сожжено» меньше.
Мой опыт говорит о том, что когда Заказчик не знает чего хочет, быстрой итерационной разработкой это не лечится.
Дальше бизнес-процесса и сценариев использования системы можно не углубляться, если у вас чистое поле или «свежий» функционал.
Но если у вас одно цепляет за другое, то это опять повод писать ТЗ и уже начинать продумывать техническое решение, что мы сможем реализовать в рамках того что сами уже сделали, а что нет и нужно предлагать Заказчику альтернативные варианты решения его бизнес-задачи.
Момент определяется достаточно просто, когда используя старую парадигму написания легкого ТЗ или без него, вы начинаете делать что-то, выпускаете обновление и что-то в другом месте отваливается.
Чем чаще и в больших местах отваливается, тем больше это становится актуальным.
Мы, страна, очень хотим развить у себя высокотехнологичное производство / высокотехнологичную экономику, и вот она наша возможность в этих проектах, направленных на помощь гражданам с ограниченными возможностями.
На счету РВК лежит 20 млрд.рублей, уже не первый год, которые ребята не знают как удачно вложить, поэтому положили на банковские депозиты.
Эти деньги можно было бы направить на финансирование обеспечения граждан с ограниченными возможностями необходимыми им устройствами для облегчения их жизни и социализации. Таким образом создав защищенный рынок для высокотехнологичной продукции, на котором ребята делающие эти проекты могли отработать технологии, найти с нашими гражданами наиболее удачные и удобные решения для продуктов, и на этой основе создать мировой конкурентоспособный продукт и его экспортировать.
Иначе велика вероятность, что закончится это всё тем, что некоторые из ребят чего-то добьются, их заметит западный инвестфонд или стратег, и выкупит их стартап, который всплывет на западе и будет обслуживать тамошний рынок и производство будет размещено там же. Так делают Германия, Япония и США опять.
А мы опять останемся с одной лишь гордостью за то, что это наши ребята придумали и сделали, но стране от этого не будет ни холодно ни жарко от этой гордости.
Так и есть, это же руки одного и того же человека.: о)
А концептуально договор между двумя людьми, который закрепляется рукопожатием выглядит иначе.
Тот концепт о котором вы говорите, скорее похож на приветствие друзей-соратников, которое происходит в верхней плоскости, вместо «традиционной» нижней.
Стоит ли начинать карьеру в игровой индустрии после 25-27 лет?
А я думаю, что никогда не поздно начать свою карьеру в той отрасли/сфере, что тебе нравится.
Жизнь по разному складывается и не всегда в начале бывает возможность начать зарабатывать себе на жизнь тем, что нравится. Поэтому работать начинаешь там, где можешь заработать деньги на себя и свою семью.
С возрастом, обретя определенную финансовую стабильность и понимание, что тебе доставляет удовольствие, открывается возможность сместить своё карьерное направление развитие в ту сферу, что нравится.
И сделать это можно поискав точки соприкосновения своего текущего ремесла и того, что хочешь. Постепенно накапливая экспертизу и предметные знания. Например, вам нравится рисовать, это ваши хобби, а зарабатываете вы продажей софта B2B (или просто занимаетесь продажами). Путь может выглядеть как переключение с продаж корпоративного софта на продажу игр и постепенное включение в какие-то проекты своей компании в качестве художника. — это эволюционный путь.
Конечно, если вы готовы все бросить и вести образ жизни студента, рисовать с утра до ночи и упорно работать, то тогда это возможно.
Это революционный путь. Он годится если есть «жир», который позволит выйти на приемлемый уровень дохода до того момента пока он кончится.
Основные задачи тестирования:
— 0 дефектов (не одна ошибка в продукте не должна просочится к клиенту)
— соответствие того, что разработано, тому что было спроектировано
Основные задачи приемо-сдаточных испытаний:
— соответствие того, что разработано, тому что было спроектировано
— соответствие результата работы функционала ожиданиям заказчика (решает ли он ту бизнес-задачу ради решения которой создавался)
Вы из тестирования начали смещаться в проектирование продукта.
Если Бизнес-Аналитик с Заказчиком и его Пользователями фантазируют как оно будет, то вы имитируете реальную работы Пользователей с Продуктом и получаете не только ошибки, не продуманные тупики в логике работы продукта, но и не выявленные раннее ожидания/требования, которые могут полностью перечеркнуть саму необходимость продукта, как в приведенном примере с АТС.
Польза этой работы, с точки зрения бизнеса и всего процесса разработки продукта, безусловна.
То что вы делаете можно с уверенностью назвать Прототипированием.
В статье проводится две линии:
«закупки» и «поставка нового кода/функций в уже существующий продукт».
Про закупки
В нашей российской реальности, если людей, которые закупают не контролировать, они от безнадзорности скатываются в откаты и в карманные фирмы. И чем больше компания, государственная или коммерческая, тем с большей вероятностью это произойдет.
Про поставку новых функций
Для меня вопрос доверять или не доверять разработчикам это вопрос используемых ими технологий и метрик.
Если уровень профессионализма высокий, количество дефектов выявляемых Клиентами равно 0 или близко к этому, количество ошибок выявляемых при тестировании минимально, то в этом случае я склонен сокращать количество проверок на выходе при доставке функционала клиенту.
Второй момент, который тут необходим это качество выполненной постановки Бизнес-аналитиком, если функционал проработан с пониманием бизнес-задачи/проблемы клиента и производимые решения практически на 100% попадают в ожидания клиентов, то я также склонен уменьшать количество выходных проверок.
Если процент попадания далек от 100%, то ещё не факт, что то что сделано/разработано должно появится на продуктиве, можно считать это созданным рабочим прототипом, с которым нужно дать поработать Пользователю-Клиенту на тестовом стенде, чтобы он уточнил своё представления и требования к ИТ-решению.
И третий момент уровень контроля должен быть соразмерен масштабу бизнеса. Представьте что через вашу систему проходит транзакций в день на 1-2 млрд.рублей, в ней работает несколько тысяч партнеров компании, компания имеет 0,5% с этого объема, представьте что вы кладете систему очередным обновлением на 1-2 дня…
Это про управление рисками.
Благодарю за статью, протер розовую пыль с очков, а то у меня была иллюзия, что надо победить в конкурсе и все нужные двери откроются. Как пишет Морейнис, мы в России, а значит на темной стороне, с первого дня у нас нет другого варианта как делать прибыльный бизнес.
Надеюсь, за год, который вас мурыжили, вы успели подготовится к roadshow по Финляндии.: о) Успеха вам там.
Об этом и речь, ресурсы размазываются ещё более тонким слоем по проектам, и сотрудники начинают задерживаться на работе чтобы успевать делать необходимое.
В конце когда происходит их «выгорание», начинается эффект домино и из ситуации «цейтнот и дэдлайны» начинается ситуация «тушения пожаров».
Направления здесь два:
1. Закладывайте в оценки трудоемкости и сроки исполнения резервы.
2. Если задач очень много, больше чем способно выполнить ваше подразделение, вам нужно изменить подход к организации работы. Сместить вектор с делать «все задачи» на «делать приоритетные задачи отталкиваясь от текущей мощности подразделения». Последнее означает следующее:
— вы с Заказчиком составляете список всех задач/заказов и приоритезируете его,
— закладываете темпо ритм производства неделю/две/месяц,
— рассчитываете мощность своего подразделения на указанный производственный промежуток,
— набираете задачи согласно приоритетам под рассчитанную мощность подразделения.
Как это выглядит «про маленькими кусочками», чтобы получалось и улучшалось:
1 этап — ваш софт это сплошной код. Добавление новой функции, постоянно оборачивается тем, что что-то падает.
2 этап — в вашем софте код начинает разбиваться на блоки, касающиеся работы отдельного функционала. Новая функция добавляется как новая размеченная область. Когда мы хотим доработать старую функцию, мы её переписываем и делаем как и новую отдельной размеченной областью. Постепенно сплошной код разносится на эти отдельные «полянки»/разделы.
Система становится более устойчивой к обновлениям. Изменения в коде известной функции, уже не отражается на коде соседней. Количество ошибок снижается, но те что появляются указывают на то, что для работы определенной функции мы меняем какие-то стратегические вещи / витальные сущности, которые используются для работы другими функциями и требуется переписывать логику их работы на такие изменения.
3 этап — в софте появляется «платформа» — это базовый функционал, которым пользуются все функции для выполнения своих задач, и она задает для них правила игры. Мы начинаем отторгать функциональный блок в отдельное приложение / дополнение к платформе. Постепенно, функция за функцией.
Вот этот внедренный подход к разработке — это +100500 в карму 1С.
Ребята встали на очень правильные рельсы, думаю это ощутила уже вся команда и это уже ощущает часть клиентов. А дальше будет ещё лучше.
Большинство других команд разработчиков в нашей о такой «технологии организации работ» пока могут мечтать.
Будучи человеком сопричастным к внедрению и развитию ИТ-систем, и находясь больше на стороне Бизнеса, болею за их «боль» (решение их проблем), могу сказать это серьезная заявка на то, что продукт 1С лет через 10 начнет вытеснять западные решения/продукты в силу лучшего понимания отечественной специфики и более высокой скорости реализации изменений.
Благодарю за статью! +1 вам в карму.
Заказчику повезло с Team Lead-ом.
Им найден способ как практически бескровно начать «апгрейдить» текущее ИТ-решение.
Правда, этот подвиг скорей всего останется не замеченным Заказчиком, но я вот для себя добавил Александра в «избранных» хабрачан, если мне или кому-то из моих друзей понадобится Мастер.
Возможно это особенность нашей страны, когда крупная компания покупает платформу от западного вендора и ваяет на её основе систему под собственные нужды, изменив её так, что ты уже не можешь обновится до следующей выпущенной версии от вендора.
В нашем случае это была Pivotal CRM и покупалась в том момент, когда система входила в лидеры квадранта Gartner. Нас оправдывает только то, что лучших практик тогда не было.
Система создавалась для развития ипотечного рынка.
Ребята ездили в Америку изучать ИТ-системы и опыт Freddie Mac и Fannie Mae.
После этого было принято решение делать своё.
Система ежегодно переваривает ипотечных закладных на 60 млрд. рублей.
Выглядит с одной стороны много, но уже с масштабами Сбербанка не сравнить.
Его ИС переваривают ипотечных закладных на 661 млрд. рублей.
Два момента:
Когда мы этот снежный ком толкнули, мы не думали о том, что нам это понадобится.
А когда он нас накрыл, не было необходимой квалификации, чтобы этот вариант реализовать. Тогда он даже не пришёл в голову, насколько смогли «подтянуть себя за волосы», из того места где сидели, настолько подтянули.
Мы лечили это следующим образом:
Знаю, что некоторые ребята не просто картинки рисуют, а создают буквально работающее решение, которое можно «покликать». Делают с помощью Axure. Почитать и посмотреть можно здесь.
Мы так и поступили, вместо того, чтобы пытаться остаться в одном, Первом ТЗ, мы создали 300.
Не за один день, но подход был выбран именно такой.
Не факт, что их нужно было 300, но это материал для «рефакторинга» ТЗ.
Если 40 ТЗ описывают одну функциональную область и каждое из них про свою процедуру, есть повод задуматься про структурирование информации.
Сейчас это проблема решена на уровне меток / тегов с названиями бизнес-процессов и бизнес-процедур, указываемых к каждому ТЗ.
Вторая статья в списке для чтения на Хабре по теме как раз про это.
Полное отсутствие ТЗ порождает Diff(-erence) между тем что сделано и ожиданиями Заказчика.
ТЗ эту разницу позволяет сократить. Что включать в ТЗ это уже предмет изучения шишек на лбу команды.
Если Заказчик не зрелый в области проектирования своих собственных бизнес-процессов, то с ним точно надо описывать Бизнес-процесс с применением ИС. Это точно лучше, чем множество итераций/спринтов, и через них приходить с ним к тому процессу который будет ему удобен и более эффективен в сравнении с тем, что у него был до этого. Будет и быстрее по времени и ресурсов «сожжено» меньше.
Мой опыт говорит о том, что когда Заказчик не знает чего хочет, быстрой итерационной разработкой это не лечится.
Дальше бизнес-процесса и сценариев использования системы можно не углубляться, если у вас чистое поле или «свежий» функционал.
Но если у вас одно цепляет за другое, то это опять повод писать ТЗ и уже начинать продумывать техническое решение, что мы сможем реализовать в рамках того что сами уже сделали, а что нет и нужно предлагать Заказчику альтернативные варианты решения его бизнес-задачи.
Момент определяется достаточно просто, когда используя старую парадигму написания легкого ТЗ или без него, вы начинаете делать что-то, выпускаете обновление и что-то в другом месте отваливается.
Чем чаще и в больших местах отваливается, тем больше это становится актуальным.
Мы, страна, очень хотим развить у себя высокотехнологичное производство / высокотехнологичную экономику, и вот она наша возможность в этих проектах, направленных на помощь гражданам с ограниченными возможностями.
На счету РВК лежит 20 млрд.рублей, уже не первый год, которые ребята не знают как удачно вложить, поэтому положили на банковские депозиты.
Эти деньги можно было бы направить на финансирование обеспечения граждан с ограниченными возможностями необходимыми им устройствами для облегчения их жизни и социализации. Таким образом создав защищенный рынок для высокотехнологичной продукции, на котором ребята делающие эти проекты могли отработать технологии, найти с нашими гражданами наиболее удачные и удобные решения для продуктов, и на этой основе создать мировой конкурентоспособный продукт и его экспортировать.
Иначе велика вероятность, что закончится это всё тем, что некоторые из ребят чего-то добьются, их заметит западный инвестфонд или стратег, и выкупит их стартап, который всплывет на западе и будет обслуживать тамошний рынок и производство будет размещено там же. Так делают Германия, Япония и США опять.
А мы опять останемся с одной лишь гордостью за то, что это наши ребята придумали и сделали, но стране от этого не будет ни холодно ни жарко от этой гордости.
А концептуально договор между двумя людьми, который закрепляется рукопожатием выглядит иначе.
Тот концепт о котором вы говорите, скорее похож на приветствие друзей-соратников, которое происходит в верхней плоскости, вместо «традиционной» нижней.
А я думаю, что никогда не поздно начать свою карьеру в той отрасли/сфере, что тебе нравится.
Жизнь по разному складывается и не всегда в начале бывает возможность начать зарабатывать себе на жизнь тем, что нравится. Поэтому работать начинаешь там, где можешь заработать деньги на себя и свою семью.
С возрастом, обретя определенную финансовую стабильность и понимание, что тебе доставляет удовольствие, открывается возможность сместить своё карьерное направление развитие в ту сферу, что нравится.
И сделать это можно поискав точки соприкосновения своего текущего ремесла и того, что хочешь. Постепенно накапливая экспертизу и предметные знания. Например, вам нравится рисовать, это ваши хобби, а зарабатываете вы продажей софта B2B (или просто занимаетесь продажами). Путь может выглядеть как переключение с продаж корпоративного софта на продажу игр и постепенное включение в какие-то проекты своей компании в качестве художника. — это эволюционный путь.
Это революционный путь. Он годится если есть «жир», который позволит выйти на приемлемый уровень дохода до того момента пока он кончится.
Основные задачи тестирования:
— 0 дефектов (не одна ошибка в продукте не должна просочится к клиенту)
— соответствие того, что разработано, тому что было спроектировано
Основные задачи приемо-сдаточных испытаний:
— соответствие того, что разработано, тому что было спроектировано
— соответствие результата работы функционала ожиданиям заказчика (решает ли он ту бизнес-задачу ради решения которой создавался)
Вы из тестирования начали смещаться в проектирование продукта.
Если Бизнес-Аналитик с Заказчиком и его Пользователями фантазируют как оно будет, то вы имитируете реальную работы Пользователей с Продуктом и получаете не только ошибки, не продуманные тупики в логике работы продукта, но и не выявленные раннее ожидания/требования, которые могут полностью перечеркнуть саму необходимость продукта, как в приведенном примере с АТС.
Польза этой работы, с точки зрения бизнеса и всего процесса разработки продукта, безусловна.
То что вы делаете можно с уверенностью назвать Прототипированием.
«закупки» и «поставка нового кода/функций в уже существующий продукт».
Про закупки
В нашей российской реальности, если людей, которые закупают не контролировать, они от безнадзорности скатываются в откаты и в карманные фирмы. И чем больше компания, государственная или коммерческая, тем с большей вероятностью это произойдет.
Про поставку новых функций
Для меня вопрос доверять или не доверять разработчикам это вопрос используемых ими технологий и метрик.
Если уровень профессионализма высокий, количество дефектов выявляемых Клиентами равно 0 или близко к этому, количество ошибок выявляемых при тестировании минимально, то в этом случае я склонен сокращать количество проверок на выходе при доставке функционала клиенту.
Второй момент, который тут необходим это качество выполненной постановки Бизнес-аналитиком, если функционал проработан с пониманием бизнес-задачи/проблемы клиента и производимые решения практически на 100% попадают в ожидания клиентов, то я также склонен уменьшать количество выходных проверок.
Если процент попадания далек от 100%, то ещё не факт, что то что сделано/разработано должно появится на продуктиве, можно считать это созданным рабочим прототипом, с которым нужно дать поработать Пользователю-Клиенту на тестовом стенде, чтобы он уточнил своё представления и требования к ИТ-решению.
И третий момент уровень контроля должен быть соразмерен масштабу бизнеса. Представьте что через вашу систему проходит транзакций в день на 1-2 млрд.рублей, в ней работает несколько тысяч партнеров компании, компания имеет 0,5% с этого объема, представьте что вы кладете систему очередным обновлением на 1-2 дня…
Это про управление рисками.
Надеюсь, за год, который вас мурыжили, вы успели подготовится к roadshow по Финляндии.: о) Успеха вам там.
Об этом и речь, ресурсы размазываются ещё более тонким слоем по проектам, и сотрудники начинают задерживаться на работе чтобы успевать делать необходимое.
В конце когда происходит их «выгорание», начинается эффект домино и из ситуации «цейтнот и дэдлайны» начинается ситуация «тушения пожаров».
1. Закладывайте в оценки трудоемкости и сроки исполнения резервы.
2. Если задач очень много, больше чем способно выполнить ваше подразделение, вам нужно изменить подход к организации работы. Сместить вектор с делать «все задачи» на «делать приоритетные задачи отталкиваясь от текущей мощности подразделения». Последнее означает следующее:
— вы с Заказчиком составляете список всех задач/заказов и приоритезируете его,
— закладываете темпо ритм производства неделю/две/месяц,
— рассчитываете мощность своего подразделения на указанный производственный промежуток,
— набираете задачи согласно приоритетам под рассчитанную мощность подразделения.
1 этап — ваш софт это сплошной код. Добавление новой функции, постоянно оборачивается тем, что что-то падает.
2 этап — в вашем софте код начинает разбиваться на блоки, касающиеся работы отдельного функционала. Новая функция добавляется как новая размеченная область. Когда мы хотим доработать старую функцию, мы её переписываем и делаем как и новую отдельной размеченной областью. Постепенно сплошной код разносится на эти отдельные «полянки»/разделы.
Система становится более устойчивой к обновлениям. Изменения в коде известной функции, уже не отражается на коде соседней. Количество ошибок снижается, но те что появляются указывают на то, что для работы определенной функции мы меняем какие-то стратегические вещи / витальные сущности, которые используются для работы другими функциями и требуется переписывать логику их работы на такие изменения.
3 этап — в софте появляется «платформа» — это базовый функционал, которым пользуются все функции для выполнения своих задач, и она задает для них правила игры. Мы начинаем отторгать функциональный блок в отдельное приложение / дополнение к платформе. Постепенно, функция за функцией.
Ребята встали на очень правильные рельсы, думаю это ощутила уже вся команда и это уже ощущает часть клиентов. А дальше будет ещё лучше.
Большинство других команд разработчиков в нашей о такой «технологии организации работ» пока могут мечтать.
Будучи человеком сопричастным к внедрению и развитию ИТ-систем, и находясь больше на стороне Бизнеса, болею за их «боль» (решение их проблем), могу сказать это серьезная заявка на то, что продукт 1С лет через 10 начнет вытеснять западные решения/продукты в силу лучшего понимания отечественной специфики и более высокой скорости реализации изменений.
Благодарю за статью! +1 вам в карму.