Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 116
Хотелось бы упрощения процесса и снижения уровня формализма (ох уж этот Ordnung), но умом понимаю, что проект с командой такого размера, просто неминуемо обрастает формальными процедурами. То что мы видели в паре банков конкурентов (в Европе и Китае), очень похоже на существующее у нас. С российским опытом практически не знаком — слышал позитивные отзывы о ВТБ и разные отзывы о Сбербанке, но с ними не работал и подробностей организации процесса просто не знаю. Уверен, что улучшить схему, хотя бы в части повышения оперативности, можно (так что советы крайне приветствуются).
По второму вопросу: схема сознательно упрощена, под шагом
скрывается примерно такой же объемный процесс определения функционального домена, выделения конкретного разработчика, контроля реализации, передачи функционала в поддержку, документированию etc. Аналогично шаги 1-2 раскрываются в схему бюджетирования, согласования функционала и прочее. В работах на этих этапах менеджер проекта принимает некоторое участие, но, по большому счету, работа менеджера сводится к замечательно формулировке «ты несешь ответственность за весь этот бардак», что означает репорты руководству, решение форс-мажоров и выбивание бюджета на следующий квартал\год. Большую часть работы руками выполняют ассистенты, мастер-тимлиды и архитектора.
По второму вопросу: схема сознательно упрощена, под шагом
5. Разработчик забирает последнюю версию исходных кодов, производит реализацию функционала.
скрывается примерно такой же объемный процесс определения функционального домена, выделения конкретного разработчика, контроля реализации, передачи функционала в поддержку, документированию etc. Аналогично шаги 1-2 раскрываются в схему бюджетирования, согласования функционала и прочее. В работах на этих этапах менеджер проекта принимает некоторое участие, но, по большому счету, работа менеджера сводится к замечательно формулировке «ты несешь ответственность за весь этот бардак», что означает репорты руководству, решение форс-мажоров и выбивание бюджета на следующий квартал\год. Большую часть работы руками выполняют ассистенты, мастер-тимлиды и архитектора.
ейчас неизвестно какими судьбами эта оценка попала автору запроса в Мадрид, но буквально на следующий день был устроен форменный разнос по видео-конференс связи, где сын какого-то испанского сотрудника в прямом эфире сделал функционал буквально за 10 минут. Понятно что парнишка использовал готовые, написанные им ранее куски SQL и Java кода, но задача, для реализации которой нужна одна таблица в БД и одна страница кода никак не тянула на 8 человеко часов.
Спасибо, развлекли старика. Напомню, что разработка эликсира бессмертия — это максимум десять минут. Задача, для решения которой нужно несколько соединений из органической химии, ну никак не тянет на сложную, ведь правда?
Проблема в том, что не-автору сходу не совсем понятно какие это должны быть
И это я еще про тестирование не говорю, code review, и то что этот десятиминутный фокус с шансами ломает десяток других мест в программе ;)
Согласен. Судя по схеме подрядчику наверное 20-40 часов нужно будет чтобы развернуть и поднять всё окружение.
В этот раз «атаку» удалось отбить. Но судя по описанию IT чрезмерно раздут и страдает гигантоманией, потому CIO первый в очереди на увольнение, а отдел IT на аутсорсинг.
В этот раз «атаку» удалось отбить. Но судя по описанию IT чрезмерно раздут и страдает гигантоманией, потому CIO первый в очереди на увольнение, а отдел IT на аутсорсинг.
Полностью согласен, гигантомания есть.
Это ж какого уровня должен быть специалист, чтобы за 10 минут (даже за час) выполнить такой объем работ:
1) Анализ существующего функционала (вдруг все уже сделано в другом месте программы)
2) Выбор оптимальной таблицы с учетом нынешних потребностей и перспективы
3) Создание таблицы (индексы, связи,...)
4) Создание Entity, DAO,…
5) Написание бизнес-логики
6) UI(!)
7) Тестирование локально
8) Вылизывание кода и комментарии
9) Ревью кода
10) Комит, пуш, тестирование на тестовом сервере
На хабре, кстати, была интересная статья Нужно отправить SMS, что может быть «проще»?
Отправка СМС — ожидание:
Отправка СМС — Реальность:
1) Анализ существующего функционала (вдруг все уже сделано в другом месте программы)
2) Выбор оптимальной таблицы с учетом нынешних потребностей и перспективы
3) Создание таблицы (индексы, связи,...)
4) Создание Entity, DAO,…
5) Написание бизнес-логики
6) UI(!)
7) Тестирование локально
8) Вылизывание кода и комментарии
9) Ревью кода
10) Комит, пуш, тестирование на тестовом сервере
На хабре, кстати, была интересная статья Нужно отправить SMS, что может быть «проще»?
Отправка СМС — ожидание:
Отправка СМС — Реальность:
Да че там, пацан сел, наговнокодил за 3 минуты — edit box без валидации с прямым INSERT в базу, структуру которой он уже знал, ни юнит-тестов, ни тестирования, ни деплоймента, ни фига. Топ-менеджемент, как обычно, схавал на лету.
сын какого-то испанского сотрудника в прямом эфире сделал функционал буквально за 10 минут.
А не пробовали такой же фокус провести со своей коммандой Java разработки?
Сдается мне, что всегда можно сделать быстрей, особенно если все уже заранее было сделано и вопрос только в том, чтобы все перепечатать и перекопировать.
А не пробовали такой же фокус провести со своей коммандой Java разработки?
Что-то подобное пробовали, с украинскими разработчиками получилось так:
Молодежь и так работает по 10-11 часов, из которых, правда, часов восемь курит доки и
Многоопытных старцев тоже не тронешь — когда случится факап, они могут найти и исправит ошибку в коробочном ПО вендора, который давно прекратил свое существование или втроем заменить команду из пяти венгров, так некстати отравившихся на праздновании дня независимости, и все сделают в срок.
Остаются разработчики среднего, как по возрасту так и квалификации, уровня. Опыта уже набравшие, но еще не заматеревшие — только вот они тоже цену себе знают и ведутся на такой спектакль только раз.
Тут нужен индивидуальный подход чуть ли не к каждому, причем «внушение» должен делать человек имеющий в глазах людей репутацию отличного разработчика. Формальная власть или власть харизмы здесь не срабатывала, только экспертная.
Молодежь и так работает по 10-11 часов
Учусь на мастера. Первое чему нас стал учить немецкий профессор на веб-инжиниринге, что все члены команды должны работать не более 8 часов и строго с выходными/праздниками, иначе люди быстро теряют мотивацию, продуктивность и все такое. В жизни похоже все не так идеально, или все таки дело в проблемах организации?
Было очень интересно читать про реальный опыт, особенно про модель системы. Было бы круто увидеть продолжение в виде подробностей, возможно о том какие фреймфорки используются для организации и планирования, разработки и оценки продукта.
Спасибо еще раз за интересную статью!
В жизни организации бывают разные с разными подходами к кадрам. Отжать и поменять — бывает вполне часто.
С другой стороны бывают люди-трудоголики, такие сами могут себя загонять — их надо в отпуск выгонять переодически.
С другой стороны бывают люди-трудоголики, такие сами могут себя загонять — их надо в отпуск выгонять переодически.
Профессор дело говорит.
«Задерживаться на работе признак непрофессионализма» (с)
Аврал это всегда стресс, ошибки, упущения, «потом переделаем», «временный костыль» и прочие прелести.
Все тут взрослые люди и понимают что авралы и факапы всегда будут, другое дело если контора работает в режиме вечного факапа, то это текучка, низкая мотивация, тлен.
Бежать длинный марафон нужно уметь.
«Задерживаться на работе признак непрофессионализма» (с)
Аврал это всегда стресс, ошибки, упущения, «потом переделаем», «временный костыль» и прочие прелести.
Все тут взрослые люди и понимают что авралы и факапы всегда будут, другое дело если контора работает в режиме вечного факапа, то это текучка, низкая мотивация, тлен.
Бежать длинный марафон нужно уметь.
Учусь на мастера. Первое чему нас стал учить немецкий профессор на веб-инжиниринге, что все члены команды должны работать не более 8 часов и строго с выходными/праздниками, иначе люди быстро теряют мотивацию, продуктивность и все такое. В жизни похоже все не так идеально, или все таки дело в проблемах организации?
два момента: первый — здесь речь шла именно про украинскую команду на нашем конкретном проекте. например венгры на проекте, на мой взгляд немного ленивы — они уже восприняли немецкий порядок в части соблюдения рабочего режима, но еще не восприняли немецкую дисциплину и чай пью когда им хочется, а не в специально отведенный получасовой перерыв один раз в день.
второй момент — именно для украинской команды такие переработки их собственная инициатива. во-первых парни видят перспективу (их мотивация): их лид вырос из junior и сейчас зарабатывает чуть ли не в полтора раза больше, чем средняя ЗП лида его квалификации в Киеве. во-вторых на проекте многому можно научиться, есть очень сильные спецы, готовые помочь, есть сложные не рутинные задачи. и третье, что как я понял привлекает — есть ощущение стабильности работодателя. банк конечно это не вам не газпром, но кризисы и 1998 и 2008 прошел, команда проекта в те времена только усилилась за счет сильных спецов, ушедших из других банков.
как итог — никто не заставляет работать по 10 часов, но если людям интересно, запрещать не будут
по поводу 8-ми часов: реальной разработкой программист занимается не более 3-4 часов в день, остальное время он думает, общается с коллегами и просто чистит мозг (анекдоты, танки, etc). здесь слова «думает, общается и чистит» — не несут негативного оттенка, это данность, которую надо принять. разрабатывать по 6-8 часов в день на протяжении длительного периода невозможно — просто снесет крышу.
Я думаю что это очень успешный и крутой проект.
Статью можно на цитаты растаскивать (-:
«Бизнес этого не понимает, поймите и вы» — хехе
«Бизнес этого не понимает, поймите и вы» — хехе
«К ИТ в целом и к проекту в частности у бизнеса было сугубо утилитарное отношение — ИТ обслуживает бизнес.»
Хех, вот и корень зла. Те, кто видят ИТ как таких себе ребят из сериала IT crowd (т.е. людей из «техподдержки») не должны допускаться к разработке на километр. Поверьте на слово.
Хех, вот и корень зла. Те, кто видят ИТ как таких себе ребят из сериала IT crowd (т.е. людей из «техподдержки») не должны допускаться к разработке на километр. Поверьте на слово.
Вот очень согласен с вами. Почему бизнес, который строится в некоторой степени на этом ПО, рассматривает разработчиков как уборщиц?
не должны допускаться к разработке на километрА они и не лезут в разработку. Это взгляд топ-менеджеров. Обидно конечно разработчикам, но если смотреть правде в глаза — внутренний IT обслуживает бизнес, а не наоборот.
Иная ситуация в компаниях-разработчиках. Совсем иная.
Наверное там отделы продаж и маркетинга носят програмистам кофе?
Пока компания маленькая — бывает и так. Потом конечно снова разделяются на заказчиков-исполнителей со всеми вытекающими.
Если компания маленькая и основана технарями — тогда может быть и так. Такая может вообще не иметь отделов продаж и марктойдов. Работает на деньги инвестора и ждет когда ее кто-нибудь купит.
Во всех остальных случаях главное — это деньги. Ради денег вся куча людей собралась. И те, кто является источником денег и заказывает музыку. А обычно деньги приходят все-таки от продаж. Если вы сделали плохой продукт, но его продали — это грустно, но не смертельно. А если вы сделали хороший продукт, но его не продали — вся компания может расходиться по домам.
Во всех остальных случаях главное — это деньги. Ради денег вся куча людей собралась. И те, кто является источником денег и заказывает музыку. А обычно деньги приходят все-таки от продаж. Если вы сделали плохой продукт, но его продали — это грустно, но не смертельно. А если вы сделали хороший продукт, но его не продали — вся компания может расходиться по домам.
Прикольно, сначала делают вывод о том что на Perl далеко не уедешь, и переписывают почти все (но не все) на Java, потом внезапно оказывается что Java сливает PHP, но PHPшный код все равно переписывают (но не весь) на Java… Похоже я ничего не понимаю в стратегии развития больших проектов.
Залог успеха большого проекта в enterprise — быть на Java
Мало того, что на Джаве, так еще и возьмут почти наверняка самые мутные из энтерпрайзных фреймворков, и будут еще удивляться потом, почему программисты неделями выпадающие списки в формочках добавляют…
Работать, в общем, надобно в продуктовых IT-компаниях.
Работать, в общем, надобно в продуктовых IT-компаниях.
В которых то же самое, только меньше волос остается. Да и плоха та продуктовая компания, которая не хочет стать еще и сервисной.
не рушьте мой мир — это абсолютно разные профили, и как следствие, разные требования к психологии программиста.
Я работаю в сервисной компании — там лишнего рубля никто не даст, если за это не платит клиент. У многих должен быть определенного градуса пофигизм (как и у любого сервиса).
Это скамейки запасных, это разные проекты, это то, во что трудно влюбиться во второй, третий и четвертый раз.
Моя компания пыталась стать продуктовой — не вышло.
Продуктовая компания — это тот же проект (да, иногда с под-проектами), это максимум несколько сфер или областей (мне больше нравится домены). Это упертость и некоторая здоровая консервативность, это болезнь «за продукт». Да, это все выходит боком, когда продукт трещит под тех. долгом, а заплатить за него компания не может.
Маразм, неадекват от профиля компании не зависит. Тонут как те, так и другие.
Я работаю в сервисной компании — там лишнего рубля никто не даст, если за это не платит клиент. У многих должен быть определенного градуса пофигизм (как и у любого сервиса).
Это скамейки запасных, это разные проекты, это то, во что трудно влюбиться во второй, третий и четвертый раз.
Моя компания пыталась стать продуктовой — не вышло.
Продуктовая компания — это тот же проект (да, иногда с под-проектами), это максимум несколько сфер или областей (мне больше нравится домены). Это упертость и некоторая здоровая консервативность, это болезнь «за продукт». Да, это все выходит боком, когда продукт трещит под тех. долгом, а заплатить за него компания не может.
Маразм, неадекват от профиля компании не зависит. Тонут как те, так и другие.
Ну если вы так хотите жить в фантазиях — ваше право.
Только вот бизнесу граздо удобней продать один раз и стричь купоны долго, чем каждый раз бегать за клиентами с продажами.
Только вот бизнесу граздо удобней продать один раз и стричь купоны долго, чем каждый раз бегать за клиентами с продажами.
Позвольте мне понять о чем вы.
Есть аутсорсинговые компании, которые продают мозги, как сервис (Epam, Luxoft, тыщи их). Зачастую они не владеют продуктами, у них много проектов с другими большими и не очень компаниями (банками, гос-вом и т.д.). Да, иногда они ведут внутренние разработки — которые выливаются в продукт, что и делает их от части продуктовыми. Но подавляющая часть прибыли — это аутсорс.
Есть компании, которые продают свой продукт по SaaS модели. Такая модель саму компанию сервисной не делает, т.к. она работает и развивает одно решение. Это решение дает основную прибыль.
С точки зрения беготня и в первом и во втором случае присутствует.
В первом бизнес парится при оценке ресурса/сделанной работе. Во втором бегает за клиентом, чтобы понять его желания и решать проблемы.
Нирваны, «продать и стричь» не вижу ни в первом, ни во втором случае…
Где же такое обитает? И что у вас сервисная компания?
Есть аутсорсинговые компании, которые продают мозги, как сервис (Epam, Luxoft, тыщи их). Зачастую они не владеют продуктами, у них много проектов с другими большими и не очень компаниями (банками, гос-вом и т.д.). Да, иногда они ведут внутренние разработки — которые выливаются в продукт, что и делает их от части продуктовыми. Но подавляющая часть прибыли — это аутсорс.
Есть компании, которые продают свой продукт по SaaS модели. Такая модель саму компанию сервисной не делает, т.к. она работает и развивает одно решение. Это решение дает основную прибыль.
С точки зрения беготня и в первом и во втором случае присутствует.
В первом бизнес парится при оценке ресурса/сделанной работе. Во втором бегает за клиентом, чтобы понять его желания и решать проблемы.
Нирваны, «продать и стричь» не вижу ни в первом, ни во втором случае…
Где же такое обитает? И что у вас сервисная компания?
Тут сливают не технологии. Достаточно посмотреть на то, сколько стадий проходит запрос фичи до реализации чтобы понять, что ничего хорошего не случается. Чем больше в цепи звеньев, тем больше она тормозится. Технологии лишь симптом.
Вы просто J2EE не видели. Там лютый бешенный ад. Более менее нормально программировать близко как на php фреймворке типа yii можно только со Spring Framework или его аналогами.
J2EE это размытый термин. Spring MVC базируется на servlet API, а это тоже часть J2EE, например.
С какого перепуга размытый? Там вполне четкая спецификация что там должно быть и как это все работает. Иначе как бы люди сертифицировали под него сервера и откуда J2EE редакция джавы берется по вашему?
Интересно много ли вам говорит словосочетание «проект на J2EE»?
Опять же, сервлеты это J2EE, JPA это J2EE — поэтому Spring MVC+Hibernate через JPA API это как-бы «J2EE».
Но думаешь то сразу о JSF+EJB и т.п. И нет никакой «четкой спецификации» касательно того, что делает проект J2EE-шным, а что — нет. Сервлеты — делают? А JPA? Может EJB или JSF? А как насчет CDI — если у меня в проекте dependency injection через Google Guice то это уже J2EE-проект?
Так много ли конкретики в вашей фразе «Вы просто J2EE не видели» — сервлетов не видели? Или CDI? Или JPA? О чем речь то — сервлеты это «лютый бешенный ад»? Несерьезно же.
Опять же, сервлеты это J2EE, JPA это J2EE — поэтому Spring MVC+Hibernate через JPA API это как-бы «J2EE».
Но думаешь то сразу о JSF+EJB и т.п. И нет никакой «четкой спецификации» касательно того, что делает проект J2EE-шным, а что — нет. Сервлеты — делают? А JPA? Может EJB или JSF? А как насчет CDI — если у меня в проекте dependency injection через Google Guice то это уже J2EE-проект?
Так много ли конкретики в вашей фразе «Вы просто J2EE не видели» — сервлетов не видели? Или CDI? Или JPA? О чем речь то — сервлеты это «лютый бешенный ад»? Несерьезно же.
Проект на J2EE говорит о использовании стека J2EE. А он вполне четко описан
Это часть J2EE
Использование технологий из стека J2EE и да Spring MVC+Hibernate это нифига не J2EE.
Конкретика вполне четкая, есть J2EE набор компонентов если вы используете их и только их то проект на J2EE. Если что-то стороннее то нет.
Опять же, сервлеты это J2EE, JPA это J2EE
Это часть J2EE
И нет никакой «четкой спецификации» касательно того, что делает проект J2EE-шным, а что — нет.
Использование технологий из стека J2EE и да Spring MVC+Hibernate это нифига не J2EE.
Так много ли конкретики в вашей фразе «Вы просто J2EE не видели» — сервлетов не видели? Или CDI? Или JPA? О чем речь то — сервлеты это «лютый бешенный ад»? Несерьезно же.
Конкретика вполне четкая, есть J2EE набор компонентов если вы используете их и только их то проект на J2EE. Если что-то стороннее то нет.
> Использование технологий из стека J2EE и да Spring MVC+Hibernate это нифига не J2EE.
Как же так — использование технологий из стека J2EE, по вашему, делает проект J2EE-шным.
А использование Spring MVC, базированного на сервлетах, и Hibernate как провайдера JPA — «это нифига не J2EE», тогда как вы сами согласились что сервлеты и JPA это часть J2EE.
Неужели не очевидно что вы сами себе противоречите?
> если вы используете их и только их то проект на J2EE
Ух ты, тоесть если у меня EJB, JSF и прочее, но затесался какой-нибудь commons fileupload или там Guice то уже все, кранты, никакого J2EE? Прикольно.
Как же так — использование технологий из стека J2EE, по вашему, делает проект J2EE-шным.
А использование Spring MVC, базированного на сервлетах, и Hibernate как провайдера JPA — «это нифига не J2EE», тогда как вы сами согласились что сервлеты и JPA это часть J2EE.
Неужели не очевидно что вы сами себе противоречите?
> если вы используете их и только их то проект на J2EE
Ух ты, тоесть если у меня EJB, JSF и прочее, но затесался какой-нибудь commons fileupload или там Guice то уже все, кранты, никакого J2EE? Прикольно.
Как же так — использование технологий из стека J2EE, по вашему, делает проект J2EE-шным.
А использование Spring MVC, базированного на сервлетах, и Hibernate как провайдера JPA — «это нифига не J2EE», тогда как вы сами согласились что сервлеты и JPA это часть J2EE.
Неужели не очевидно что вы сами себе противоречите?
Внимательно прочитайте. Spring MVC не часть J2EE. Я без всяких проблем могу его запустить на сервере tomcat который не обладает поддержкой J2EE стека.
Ух ты, тоесть если у меня EJB, JSF и прочее, но затесался какой-нибудь commons fileupload или там Guice то уже все, кранты, никакого J2EE? Прикольно.
В случае использования Guice да. В случае commons fileopload нет. В Guice да так-как у J2EE есть свой метод связывания компонент.
> Я без всяких проблем могу его запустить на сервере tomcat который не обладает поддержкой J2EE стека
Так мы ж о сервлетах говорили, и вы сами написали что это — часть J2EE. А теперь говорите что Томкет, хоть и сервлет контейнер, и Spring MVC хоть и базируются на сервлетах — это не J2EE. И еще и мне советуете «внимательно читать» — забавно.
> В Guice да так-как у J2EE есть свой метод связывания компонент.
В J2EE «свой метод» это CDI, JSR299, но JSR299 базируется на JSR330 — а JSR330 это Guice: java.dzone.com/articles/what-relation-betwe-there
Так мы ж о сервлетах говорили, и вы сами написали что это — часть J2EE. А теперь говорите что Томкет, хоть и сервлет контейнер, и Spring MVC хоть и базируются на сервлетах — это не J2EE. И еще и мне советуете «внимательно читать» — забавно.
> В Guice да так-как у J2EE есть свой метод связывания компонент.
В J2EE «свой метод» это CDI, JSR299, но JSR299 базируется на JSR330 — а JSR330 это Guice: java.dzone.com/articles/what-relation-betwe-there
The relation between JSR-299 and JSR-330 is comparable to the relation between JPA and JDBC. JPA uses internally JDBC, but you can still use JDBC without JPA. In Java EE 6 you can just use JSR-330 for basic stuff, and enhance it on demand with JSR-299. There is almost no overlap in the practice. You can even mix JSR-299 / JSR-330 with EJB 3.1 — to streamline your application.
Так мы ж о сервлетах говорили, и вы сами написали что это — часть J2EE. А теперь говорите что Томкет, хоть и сервлет контейнер, и Spring MVC хоть и базируются на сервлетах — это не J2EE.
Напоминаю тем кто в танке. Под J2EE подразумевается полный и доступный стек технологий. Проще говоря если я пишу в пределах стека J2EE, то в случае если сервер приложений или SDK его поддерживают мне ничего дополнительно ставить не надо.
В J2EE «свой метод» это CDI, JSR299, но JSR299 базируется на JSR330 — а JSR330 это Guice: java.dzone.com/articles/what-relation-betwe-there
Смотрим выше. Если я захочу в J2EE сервере приложений использовать Guice, то мне надо будет эту библиотеку самому добавить в свое приложение.
Смотрим выше. Если я захочу в J2EE сервере приложений использовать Guice, то мне надо будет эту библиотеку самому добавить в свое приложение.
Тоесть один и тот же код в котнейнере который провайдит JSR330 за счет встроенного Weld будет J2EE, а в Томкете с прикрученным руками Guice будет уже не J2EE.
Однако, очень четкое различие между J2EE и не-J2EE проектами.
Еще раз для тех кто в танке есть J2SE SDK и J2EE SDK что в ходит в ту и в ту часть можно почитать на сайте оракл. В случае если проект написан под J2EE он подразумевает использования этого стека технологий Guice прикрученный руками в tomcat это не J2EE. У tomcat есть отдельная редакция сертифицированная под J2EE.
Всегда было интересно, есть ли в Web Profile направлении фреймворки типа PHPшных. Изначально ведь «JSP — это как PHP, только Java».
Возможно, есть более удобные фреймворки для работы в вебе? Например, Vaadin.
Возможно, есть более удобные фреймворки для работы в вебе? Например, Vaadin.
Напротив улучшения с комментированием новостей стояла трудоемкость — 8 человеко-часов. Сейчас неизвестно какими судьбами эта оценка попала автору запроса в Мадрид, но буквально на следующий день был устроен форменный разнос по видео-конференс связи, где сын какого-то испанского сотрудника в прямом эфире сделал функционал буквально за 10 минут.
Он за 10 минут сделал прототип, а не production функционал.
Для production надо еще:
1) понять что надо сделать. Не на уровне «одна таблица в бд», а на уровне бизнес-функционала.
2) написать таки код
3) интегрировать код в проект
4) сделать скрипты миграции для БД
5) поправить по результатам тестирования
Это все вместе займет часа 2-3 при inhouse если знать что делать. А при аутсорсе это еще и затраты на коммуникацию. Так что 8 часов выглядит вполне адекватной оценкой с учетом рисков.
Да это вообще смешно про 10 минут, по сути он сделал только один пункт (№5) из 30-ти пунктов в workflow автора статьи. Оценка в 8 часов — реальна.
8 человеко-часов это еще по божески. Обычно в больших проектах, как в старой байке — доллар за удар кувалдой и 999 долларов за знание куда ударить (в контексте статьи «доллар» = «человеко/минута»).
Иногда проблема решается одной строчкой кода, но на запуск этой строки в продуктив, тратятся часы (даже дни).
Иногда проблема решается одной строчкой кода, но на запуск этой строки в продуктив, тратятся часы (даже дни).
4.Совет руководителям проекта. В классическом треугольнике качество-сроки-бюджет, бюджет как правило зафиксирован, категория качества является для топ-менеджмента довольно абстрактной (сокращать функционал не дают, так что качество это именно качество), так что вместо треугольника готовьтесь воевать только на одном фронте — фронте сроков. Просто учитывайте это при планировании.
А где совет то? Правило треугольника как раз говорит что все три вершины зафиксировать нельзя. Можно зафиксировать одну из них, например бюджет. При зафиксированном бюджете команда установит объем функционала и будет варьировать сроки реализации путем изменения количества привлеченных разработчиков.
Если тебе дают хотя бы две зафиксированные вершины, то варьировать уже нечего.
Кстати в оригинале в треугольнике нету «качества», есть объем, срок и бюджет. Качество присутствует во всех трех неявно. Причем зависимость явно нелинейная, поэтому нельзя просто обменять качество на срок.
Вообще — молодцы. При таком масштабе проекта не скатится в хаос, применять современные подоходы и инструменты, все вот эти ревью кода, статический анализ и т.д. — респект.
Почему-то мне кажется, что причина — не модно. Java — модно, а Perl — нет.
С PHP дальше раскрывается — «о преимуществах слушать не хотим, хотим Java, но не можем протолкнуть начальству».
С PHP дальше раскрывается — «о преимуществах слушать не хотим, хотим Java, но не можем протолкнуть начальству».
Опишите пожалуйста проблемы из-за которых было принято решение мигрировать с Perl. Не холивара ради, просто чтобы все перловики знали где нужно быть осторожней.
Решение, насколько я знаю, принималось в конце прошлого\начале текущего века — так что могу только гадать на основе «случайно услышанных баек». Инициатором миграции была верхушка ИТ блока, цели — самые благородное: необходима платформа для больших проектов, от известного вендора, с поддержкой, желательно поставляющего вообще весь стек ИТ продуктов. Собственно альтернатив J2EE на тот момент, как я понимаю не было: Microsoft Net только становился на ноги. Позиции IBM в финансовом секторе вообще и в банке в частности были сильны, так что голубой гигант победил без особой борьбы: IBM стал не только поставщиком железа и сервисов, но протолкнул и вебсферу (не портал, только application server). Ключевые слова в продаже, думаю, с тех пор не сильно изменились: поддержка крупного вендора, масштабируемость, надежность.
Вы описали очень крутой ад. Ничего лучше горизонтально масштабированной структуры с инкапсуляцией всех компетенций внутри команд (анализ+разработка +тестирование) еще не придумали. У всех лидеров так. У вас же сейчас дикий оверхед на коммуникациях, неповоротливость и несогласованность стратегии развития.
Такая структура как у вас подходит для водопада. Но у вас нифига не водопад, требования сыпятся хаотично (во всяком случае, так я трактую наличие личного бюджета подразделений на it игрушки), поэтому и структура должны отражать реальность. Реальность под структуру все равно подогнать не удастся :)
Вы описали очень крутой ад. Ничего лучше горизонтально масштабированной структуры с инкапсуляцией всех компетенций внутри команд (анализ+разработка +тестирование) еще не придумали
Если я вас правильно понимаю, речь про множество сравнительно небольших команд, в каждой из которых присутствуют все нужные для разработки компетенции? Если так, то мы это проходили — не срослось. Простые кейсы:
1. Пришел новый запрос, кто решает в какую из команд его отдавать?
2. Ок, как-то решили, какая из мини команд делает, как обеспечить чтобы новый функционал нормально жил с уже существующим (не дублировал, то что уже есть, использовал интерфейсы к внешним системам, которые — интерфейсы, уже описаны и зафиксированы etc)?
3. Будет ли балансировка ресурсов между командами? Условно — у кого-то простаивает 5-ть разработчиков, а в другой команде завал — люди будут «передаваться» из команды в команду?
4. Как планировать финансы на все команды? Сверху вниз или снизу вверх? В первом варианте кто будет решать, кому какая доля, а во втором, кто будет защищать бюджеты перед топами?
5. Кто несет ответственность за весь проект в целом? В том смысле кто репортит топам за весь проект, кого режут на части в случае факапа, кто консолидирует требования от миникоманд, чтобы, например вместо 10-ти минисерверов разработки для каждой команды купить одну мега-железку?
Для ответов на все эти вопросы и существует адова иерархия с единой для всех командой архитекторов, единой командой мастер-лидов для балансировки ресурсов, единым менеджером…
Впрочем, я нахожусь внутри, поэтому изначально субъективен, если есть успешные кейсы, скажите где смотреть, читать или куда напрашиваться на референс визит — буду искренне благодарен, сам устал от всей этой иерархии.
1. У каждой из команд есть зона ответственности которая обозначена для конечных пользователей. Берет ли он запрос решает ПМ команды, он же перекидывает его на другую команду если считает что это нужно. Можно подумать и над диспетчером клиентских запросов, но это решение сразу хуже, т.к. вносит доп. сложность.
2. Аналитик никуда не девается, это его задача.
3. Нет, люди не передаются. Если люди простаивают временно — се ля ви. Если хронически, то отдавать их насовсем и делать команду меньше. Передача людей на время превращает все в бардак.
4. Не знаю :) Сильно зависит от начальных данных по финансам, я их пока слабо понимаю.
5. Есть главный ПМ проекта и главный технический лидер. Они не вникают в мелочи, но принимают решение по крупняку и несут ответственность за подчиненных.
Куда сделать референс визит к сожалению сейчас подсказать не могу. На предыдущем месте работы разбиение иерархии и выстраивание четких команд со своей зоной ответственности дало увеличение производительности в 3-4 раза (по реализованным в месяц фичам). Я одной из таких команд руководил, поэтому все видел собственными глазами.
2. Аналитик никуда не девается, это его задача.
3. Нет, люди не передаются. Если люди простаивают временно — се ля ви. Если хронически, то отдавать их насовсем и делать команду меньше. Передача людей на время превращает все в бардак.
4. Не знаю :) Сильно зависит от начальных данных по финансам, я их пока слабо понимаю.
5. Есть главный ПМ проекта и главный технический лидер. Они не вникают в мелочи, но принимают решение по крупняку и несут ответственность за подчиненных.
Куда сделать референс визит к сожалению сейчас подсказать не могу. На предыдущем месте работы разбиение иерархии и выстраивание четких команд со своей зоной ответственности дало увеличение производительности в 3-4 раза (по реализованным в месяц фичам). Я одной из таких команд руководил, поэтому все видел собственными глазами.
Давайте разберем конкретный кейс, чтобы спуститься с абстрактных рассуждений до конкретного примера:
Заказчик хочет новую форму расчета бонуса с продаж. Функционально задача касается нескольких команд:
1. Есть хранилище, где лежат данные по продажам. Поддерживает DWH одна команда.
2. Информация по платежам и ФОТу лежит, условно, в HRMS, который поддерживает вторая команда.
3. Бонус зависит в т.ч. от KPI подразделения и филиала в целом, которые вычисляется в третьей коробке Balanced ScoreCard Manager.
4. Системы, упомянутые в п.1-3 это backend, интерфейс к ним разрабатывает четвертая команда (на самом деле интерфейс к DWH разрабатывает еще одна команда BI).
Теперь внимание вопрос: кому из ребят достанется заказ? Можно отдавать тем, на чей модуль ляжет больше функционала. Можно отдавать тем, у кого есть свободные ресурс. Можно отдавать тем, кто лучше (в срок и бюджет) выполнил предыдущую задачу. Все эти критерии очень условно, функционал плохо взвешивается, все друг с другом воюют за деньги и власть. Плюс т.к. функциональность касается нескольких систем, кто будет контролировать процесс в целом? Чтобы и рукава и пуговицы были в порядке и никто из команд не тянул одеяло сроков и денег на себя?
Второй момент — если аналитик прикреплен к команде, то он не видит картинки в целом и просто не знает, что делали соседи. Значит нужен аналитик, точнее архитектор, кто видит картинку сверху и знает, хотя бы по верхам, что делает каждая команда.
Т.е. сама идея горизонтального масштабирования жизнеспособна и в какой-то мере красива, но как ее применить у себя — способа не вижу.
Заказчик хочет новую форму расчета бонуса с продаж. Функционально задача касается нескольких команд:
1. Есть хранилище, где лежат данные по продажам. Поддерживает DWH одна команда.
2. Информация по платежам и ФОТу лежит, условно, в HRMS, который поддерживает вторая команда.
3. Бонус зависит в т.ч. от KPI подразделения и филиала в целом, которые вычисляется в третьей коробке Balanced ScoreCard Manager.
4. Системы, упомянутые в п.1-3 это backend, интерфейс к ним разрабатывает четвертая команда (на самом деле интерфейс к DWH разрабатывает еще одна команда BI).
Теперь внимание вопрос: кому из ребят достанется заказ? Можно отдавать тем, на чей модуль ляжет больше функционала. Можно отдавать тем, у кого есть свободные ресурс. Можно отдавать тем, кто лучше (в срок и бюджет) выполнил предыдущую задачу. Все эти критерии очень условно, функционал плохо взвешивается, все друг с другом воюют за деньги и власть. Плюс т.к. функциональность касается нескольких систем, кто будет контролировать процесс в целом? Чтобы и рукава и пуговицы были в порядке и никто из команд не тянул одеяло сроков и денег на себя?
Второй момент — если аналитик прикреплен к команде, то он не видит картинки в целом и просто не знает, что делали соседи. Значит нужен аналитик, точнее архитектор, кто видит картинку сверху и знает, хотя бы по верхам, что делает каждая команда.
Нет, люди не передаются. Если люди простаивают временно — се ля виПростите, но людям в простое надо платить зарплату? Если да, но при этом ресурсы умышленно не балансируются между командами — вы такой подход нивжисть не объясните бизнесу.
Есть главный ПМ проекта и главный технический лидерТак а я о чем? Есть главный РП, есть несколько архитекторов, один их них главный, есть команды со своими лидами. В результате получилась текущая схема, с «адовой» иерархией: РП-мастерлид-лид-разработчик. Убрать мастерлидов не получится, если у лида не более 7-ми разработчиков, то получится что РП надо будет общаться с 20-30 лидами, что полностью убьет управляемость.
Т.е. сама идея горизонтального масштабирования жизнеспособна и в какой-то мере красива, но как ее применить у себя — способа не вижу.
Простите, но людям в простое надо платить зарплату? Если да, но при этом ресурсы умышленно не балансируются между командами — вы такой подход нивжисть не объясните бизнесу.
Нужно пытаться, в бизнесе же тоже не идиоты сидят. Балансировка ресурсов — нормальный подход для потока однородных проектов небольшого размера, где существует хорошая заменимость специалистов. Веб студии так работают. Для сложных систем, где на изучение каждого куска нужно тратить много времени этот подход просто не подходит.
По вашему кейсу мне сложно что-то придумать, так как я не знаю, за что именно дерутся ваши команды. Если они хотят себе больше задач, денег и власти то это на самом деле очень круто, вы можете устраивать между ними аукцион и отдавать таск тому, кто предложит лучшие условия. Но гораздо чаще встречаются ситуации, когда команды играют в пинг-понг тухлыми тикетами, не желая их брать вообще.
Ну и еще замечание. Я бы никогда не отдал интерфейс в отдельную команду. У каждой из команд должны быть компетенции полностью реализовать фичу. Т.е. и в интерфейсе тоже. Просто потому, что интерфейс неразрывно связан с функционалом, особенно в подобных корпоративных системах.
А как велось (и велось ли вообще) управление требованиями?
Я могу сильно ошибиться, но BPM, как и ClearCase, и тем более Issue tracker не самые подходящие инструменты для отслеживания поступающих требований.
Тем более в условиях, когда нет владельца продукта и очередей поступающих задач более двух. Плюс еще очередь из срочных задач, багов и т.п.
Управление требованиями сильно помогает при обучении новых сотрудников — про on-boarding, кстати, ни слова. Текучка на большом проекте совсем другая, чем на маленьком.
Менялся ли процесс в зависимости от команды?
Например, у Java команды куда больше телодвижений нужно совершить, чтобы выпустить версию, в то время как у php команды может не хватать общепризнанных решений (как, например, Composer — мы адаптировали ant/maven для той же цели).
А что было у программиста?
Т.е. был ли какой-либо стандарт на окружение у разработчика, лида или вхождение в проект начиналось с настройки окружения?
Можно еще пару слов об атмосфере на проекте?
На нашем проекте «удаленность» ощущалась весьма остро, вплоть до недоверия, непонимания и взаимного переписывания кода. Мы были маленькими и о тестах либо не слышали, либо откладывали. Решение было очень логичным — в этот самый период вторую (или первую :) команду привезли на месяц или полтора к нам. Все проблемы с коммуникацией были решены, атмосфера улучшилась. Да, код идеальным не стал и его работоспособность от выпитого в баре не улучшалась, но стабильность начала повышаться и баги стали уменьшаться.
Я могу сильно ошибиться, но BPM, как и ClearCase, и тем более Issue tracker не самые подходящие инструменты для отслеживания поступающих требований.
Тем более в условиях, когда нет владельца продукта и очередей поступающих задач более двух. Плюс еще очередь из срочных задач, багов и т.п.
Управление требованиями сильно помогает при обучении новых сотрудников — про on-boarding, кстати, ни слова. Текучка на большом проекте совсем другая, чем на маленьком.
Менялся ли процесс в зависимости от команды?
Например, у Java команды куда больше телодвижений нужно совершить, чтобы выпустить версию, в то время как у php команды может не хватать общепризнанных решений (как, например, Composer — мы адаптировали ant/maven для той же цели).
А что было у программиста?
Т.е. был ли какой-либо стандарт на окружение у разработчика, лида или вхождение в проект начиналось с настройки окружения?
Можно еще пару слов об атмосфере на проекте?
На нашем проекте «удаленность» ощущалась весьма остро, вплоть до недоверия, непонимания и взаимного переписывания кода. Мы были маленькими и о тестах либо не слышали, либо откладывали. Решение было очень логичным — в этот самый период вторую (или первую :) команду привезли на месяц или полтора к нам. Все проблемы с коммуникацией были решены, атмосфера улучшилась. Да, код идеальным не стал и его работоспособность от выпитого в баре не улучшалась, но стабильность начала повышаться и баги стали уменьшаться.
… в генеральные директора чаще попадают с места финансового директора, но почти никогда с места директора ИТ ...
Для банка — это самое естественное карьерное развитие. Все таки, управлять финансовым институтом должен человек с финансовым же образованием. Вы же не поймете, если у руля MS или Гугла встанет крутой дядька, бывший финансист, который в технологиях ни алё.
CIO из банка переходят потом как VP или другие executive (помогите с переводом) в продуктовые или аутсорсинговые IT компании — им там и тепло, и уютно и, главное, сухо.
IТ, это обслуга
Не соглашусь. По крайне мере, не на 100%. Для меня IT и бизнес — две противоположности.
IT хочет много денег и времени для идеального кода, продукта, сервиса.
Бизнес хочет «сейчас» и «дешево», ему насрать (да, насрать) на идеал. И как старший брат, он прав. Крупный банк может пережить целые эпохи (Wells Fargo), а вы все о чем-то мелком… новые продукты, языки, эффективность…
Если побеждает IT — бизнес скатывается в убыток (да, есть исключения).
Если побеждает бизнес, то IT обслуга, а то и рабы — ни люди, а body.
Мой совет — если ты разработчик и, тем более, лид — борись за продукт. Отстаивай его чистоту, бейся за качество.
Спойлер
да, это тяжело — справляются не все. И без фанатизма — фанатиков никто не любит. Но если его умело спрятать, никто и не поймет. Главное, если решите развалить чужой бизнес, то хотя бы знайте «зачем». =)
Если ты заказчик, и если вы знаете про Win-Win…
Спойлер
… то мне вам сказать больше нечего =) Вы лучше меня знаете что и как делать.
Вангую пост «Другая история тяжелого проекта: без бюрократии, на коленке, все счастливы, мир а не война»
Поделюсь своим опытом. Проект не такой огромный — около 40 разработчиков, но есть еще кастомизации, поддержка и многочисленные «spin-off'ы».
Мое субъективное мнение, что разработчиков уровня ниже senior (или «почти senior») вообще не имеет смысл нанимать на работу над такими проектами, потому что фактически КПД junior'ов скорее отрицательно. Самостоятельно написать код без тех. долга они все-равно не могут, при этом отнимают достаточно много времени «старших» разработчиков. В итоге лиды и синьоры перегружены и почти не пишут кода, потому что все их время съедают консультации «молодняка» и рефакторинг (читай выбрасывание и переписывание) того, что написалииндусы коллеги.
Джуниору платят обычно не особенно много (по меркам IT), поэтому понабравшись «по-верхам» от более опытных коллег, через пол годика джуниор считает, что теперь он «синьор», поэтому сваливает на +$300 в ООО «Рога и Копыта» с вашими инвистициями в его образование.
В итоге получается ситуация, в которой большую часть времени все ходят и разговаривают, что же нужно делать. Субъективно «дрим-тим» из 10 чеовек будет работать эфективнее, чем 50 специалистов уровня «ну ок» и «ниче, скоро научится». При этом, да, существует проблема: таких специалистов на рынке очень мало и кждый человек получается на вес золота. Кроме этого, сдвинуть уже сложившуюся парадигму довольно сложно.
По поводу «обслуги» мысль в целом правильная, но стоит добавить, что грамотный CIO может выстроить «партнерские» отношения с бизнесом. Главное говорить на одном языке. IT будут слушать, если у «технарей» будут аргументы понятные бизнесу.
Мое субъективное мнение, что разработчиков уровня ниже senior (или «почти senior») вообще не имеет смысл нанимать на работу над такими проектами, потому что фактически КПД junior'ов скорее отрицательно. Самостоятельно написать код без тех. долга они все-равно не могут, при этом отнимают достаточно много времени «старших» разработчиков. В итоге лиды и синьоры перегружены и почти не пишут кода, потому что все их время съедают консультации «молодняка» и рефакторинг (читай выбрасывание и переписывание) того, что написали
Джуниору платят обычно не особенно много (по меркам IT), поэтому понабравшись «по-верхам» от более опытных коллег, через пол годика джуниор считает, что теперь он «синьор», поэтому сваливает на +$300 в ООО «Рога и Копыта» с вашими инвистициями в его образование.
В итоге получается ситуация, в которой большую часть времени все ходят и разговаривают, что же нужно делать. Субъективно «дрим-тим» из 10 чеовек будет работать эфективнее, чем 50 специалистов уровня «ну ок» и «ниче, скоро научится». При этом, да, существует проблема: таких специалистов на рынке очень мало и кждый человек получается на вес золота. Кроме этого, сдвинуть уже сложившуюся парадигму довольно сложно.
По поводу «обслуги» мысль в целом правильная, но стоит добавить, что грамотный CIO может выстроить «партнерские» отношения с бизнесом. Главное говорить на одном языке. IT будут слушать, если у «технарей» будут аргументы понятные бизнесу.
Команда звёзд далеко не всегда становится звёздной командой.
Скажем так, если говорить в терминах AD&D мне всегда было наиболее комфортно работать в партии с мульти-классами, скажем full-stack-dev + qa + test automation, backend-dev + system-administrator, frontend-dev + UI/UX + BA. Таким образом сильно сокращаются накладные расходы, например: не надо сначала давать верстальщику макет, а потом «натягивать» его на двидок. Просто беершь и сразу верстаешь туда, куда надо.У facebook'а была где-то статья «почему мы нанимаем только full stack». Похожая ситуация в skype. Не знаю изменилось что-то после покупки майкрософтом, но до этого у них не было разделение на разработчиков и системных администраторов.
Понятно, что при этом у людей должны быть навыки командной работы. Я вообще считаю, что «аутистов» следует нанимать в одном единственном случае — человек умеет делать что-то ну ооочень уникальное.
Понятно, что при этом у людей должны быть навыки командной работы. Я вообще считаю, что «аутистов» следует нанимать в одном единственном случае — человек умеет делать что-то ну ооочень уникальное.
Безусловно, вы правы.
Но команда, состоящая из звёзд, и при этом являющаяся ещё и звёздной командой, — большая редкость.
Все со своими характерами, амбициями и т.п.
И по крайней мере по своему опыту могу сказать, что держать усилия такой команды в одном русле и одном направлении — дьявольски тяжело.
Конфликты неизбежны.
По поводу junior'ов. Правильная работа с junior'ами бывает очень полезна не только для junior'ов, но и для coach'ей. Пусть даже они это не понимают или не хотят признавать. Junior'ами когда-то были все.
Но команда, состоящая из звёзд, и при этом являющаяся ещё и звёздной командой, — большая редкость.
Все со своими характерами, амбициями и т.п.
И по крайней мере по своему опыту могу сказать, что держать усилия такой команды в одном русле и одном направлении — дьявольски тяжело.
Конфликты неизбежны.
По поводу junior'ов. Правильная работа с junior'ами бывает очень полезна не только для junior'ов, но и для coach'ей. Пусть даже они это не понимают или не хотят признавать. Junior'ами когда-то были все.
Верно. Нужен еще звездный руководитель, который умеет ее собрать воедино.
грамотный CIO может выстроить «партнерские» отношения с бизнесомКак правило отношения скатываются к стандартному заказчик-исполнитель. Просто потому, что это максимально формализованный и давно проработанный бизнес-процесс. К сожалению далеко не самый эффективный, по одной простой причине — у заказчика и исполнителя разные цели. Хотя де-факто они над одной проблемой работают внутри организации.
Это не объяснение отношения как к «обслуге».
Причина такого отношения не в структуре организации или целях заказчика или исполнителя.
Причина банально в непрофессионализме.
В случае, описанном в топике, руководство IT — очень важные стейкхолдеры, с которыми не считаются.
А это очень важно — уметь с ними работать.
Даже уборщица может оказаться очень важным и влиятельным стейкхолдером.
Причина такого отношения не в структуре организации или целях заказчика или исполнителя.
Причина банально в непрофессионализме.
В случае, описанном в топике, руководство IT — очень важные стейкхолдеры, с которыми не считаются.
А это очень важно — уметь с ними работать.
Даже уборщица может оказаться очень важным и влиятельным стейкхолдером.
У вас автомобиль есть? Как вы относитесь к работникам автосервиса? Вы с ними как добрые друзья и партнеры разбираете мотор и решаете как лучше быть?
А между тем автомобиль это и ваша безопасность и ваш комфорт и ваши деньги.
А между тем автомобиль это и ваша безопасность и ваш комфорт и ваши деньги.
Но я точно не хватаю первого же мастера за грудки с порога со словами «Если с машиной чо не так будет — лично тебе башку снесу!»
Безусловно, доверяй, но проверяй.
Но в разумных пределах.
А вообще сравнение не очень корректное.
В вашем сравнении я почему-то стал заказчиком.
Безусловно, доверяй, но проверяй.
Но в разумных пределах.
А вообще сравнение не очень корректное.
В вашем сравнении я почему-то стал заказчиком.
Но я точно не хватаю первого же мастера за грудки с порога со словами «Если с машиной чо не так будет — лично тебе башку снесу!»Разработчикам тоже никто не угрожает. В автосервисе вы регулярно платите деньги — они чинят и проводят профилактику. Причем ваша цель сделать побыстрее и качественнее за возможно меньшие деньги, а цель сервисмена — поменять этот чертов фильтр и продуть форсунки и получить за это свою трудовую копейку от руководства сервиса. По-моему очень неплохая аналогия.
В вашем сравнении я почему-то стал заказчиком.Так это для того чтобы вам проще было понять позицию топов того банка.
Позиция ясна.
Но вменяемость тоже никто не отменял.
Не считаться с людьми, от которых напрямую зависит качество продукта, — не очень вменяемо.
Но вменяемость тоже никто не отменял.
Не считаться с людьми, от которых напрямую зависит качество продукта, — не очень вменяемо.
Не считаться с людьми, от которых напрямую зависит качество продукта, — не очень вменяемо.Ну что значит «не считаться»? Вы грубите официантам и выливаете им на голову кофе? Нет, вы относитесь как ним как к людям, обслуживающим вас. Даже чаевые оставляете (иногда).
Для меня официант или повар — особенно, если я впервые пришёл в это заведение, — это эксперты, которые могут мне выбрать вкусное блюдо или напиток, которые станут звеньями в той последовательности, которую я и назову «хорошо проведённое время» или как-то ещё — в зависимости от моих целей.
Их цель не только приготовить и принести мне выбранное блюдо, но и удовлетворить мои потребности, оставить хорошее впечатление об их работе, чтобы я и сам ещё раз пришёл, и друзей привёл.
Если я с порога на официанта наору, он хоть и принесёт мне блюдо, которое я прошу, но вряд ли поинтересуется, понравилось ли мне оно или посоветует вкусный десерт. И вряд ли захочет увидеть меня ещё раз, даже если сумма моего счёта будет выше средней. И если это лучший ресторан в мире, то в проигрыше остаюсь я, а не они.
Вот и в случае с топ-менеджерами того банка такая же история. Если я как представитель IT выполняю на все 100% свою работу, а они со мной считаться не хотят, вряд ли я захочу с ними работать ещё раз. И либо у них ничего не получится с продуктом, либо они потеряют команду, которая выкладывается для них на все 100%. Ни то, ни другое им не понравится.
Их цель не только приготовить и принести мне выбранное блюдо, но и удовлетворить мои потребности, оставить хорошее впечатление об их работе, чтобы я и сам ещё раз пришёл, и друзей привёл.
Если я с порога на официанта наору, он хоть и принесёт мне блюдо, которое я прошу, но вряд ли поинтересуется, понравилось ли мне оно или посоветует вкусный десерт. И вряд ли захочет увидеть меня ещё раз, даже если сумма моего счёта будет выше средней. И если это лучший ресторан в мире, то в проигрыше остаюсь я, а не они.
Вот и в случае с топ-менеджерами того банка такая же история. Если я как представитель IT выполняю на все 100% свою работу, а они со мной считаться не хотят, вряд ли я захочу с ними работать ещё раз. И либо у них ничего не получится с продуктом, либо они потеряют команду, которая выкладывается для них на все 100%. Ни то, ни другое им не понравится.
Я говорю именно про работу «над одной проблемой». Можно выстроить отношения не «я начальник ты дурак», а «мы хотели бы видеть такую функциональность, как это лучше реализовать технически», когда полный вижн складывается с двух сторон.
Заказчик-исполнитель это совсем не начальник-подчиненный.
мы хотели бы видеть такую функциональность, как это лучше реализовать техническиИ что думаете предложит заказчику грамотный РП? Он скажет — нам нужен месяц на проработку ваших требований, потом скажет полгода надо пилить. И вообще лучше бы переписать вот это и вот это. А это еще год займет. Заказчику эти расходы не нужны и сроки не устраивают. А РП не хочет рисковать, давая нереальные обещания. А еще есть команда, которой в общем-то наплевать на пожелания заказчика, у них свои KPI. И этот клубок противоречивых целей и желаний начинает наполнятся эмоциями и взаимной неприязнью. Проходил лично.
У меня нет неприязни к клиентам. Я их наоборот люблю. И KPI у нас одинаковый — сделанная работа.
У вас внутренний бизнес-заказчик, а вы разработчик? «Сделанная работа» для вас и для вашего клиента это одно и то же?
Сейчас работаю аутсорсером. В продуктовой компании тоже работал. Да, «сделанная работа» — одно и то же. Меня очень раздражает распространенное мнение разработчиков, что «сделанная работа» — это какой-то там код, который где-то закомичен. Для меня «сделанная работа» — это выложенный на боевые сервера функционал. На всякий случай уточню, что я сам пишу код последние 8 лет.
ОК, наверное вы сталкивались с задачами, которые делает не один разработчик а 5. А иногда 50. Каждый из них пилит свой кусок. Для них тоже «сделанная работа» — это отправка в продакшн?
Да, у GitHub это отлично получается: habrahabr.ru/post/197026/.
Погодите, я говорю о ситуации, когда работа одного разработчика — это несамостоятельная часть решения, не несущая конечной пользы заказчику.
Вот Васе поставили задачу — добавить в БД таблицу. Все остальное делают другие. Вася сделал это за час и ждет справедливой похвалы. А его коллеги «просрали все полимеры» и ничего не успели. Работа для заказчика не сделана, Вася остался без премии.
Вот Васе поставили задачу — добавить в БД таблицу. Все остальное делают другие. Вася сделал это за час и ждет справедливой похвалы. А его коллеги «просрали все полимеры» и ничего не успели. Работа для заказчика не сделана, Вася остался без премии.
Это какое-то непонимание или демагогия. Если работа — часть фичи или рефакторинг, который поможет в будущем сократить время на багфиксы и избежать ошибок — это прямая польза для заказчика. Назовите это «сокращение издержек», а не «рефакторинг» и вас отлично поймет бизнес.
Если работа в денежном представление не несет никакой прибыли — она бесполезна и не надо ей заниматься.
Если работа в денежном представление не несет никакой прибыли — она бесполезна и не надо ей заниматься.
Может мы о несколько разный масштабах говорим? Вот ко мне как к РП приходит Заказчик, говорит я хочу такую фичу. Я говорю — ОК, 5 человек это будут делать 3 месяца. Договорились и начали работать. Требование заказчика декомпозируется в несколько десятков или даже больше сотни отдельных подзадач. Заказчик естественно ничего о них не знает да и не должен. Ему нужен существенный для него результат — фича которую он хотел, в срок о котором мы договорились.
Понял. Можно мыслить следующим образом. Например, есть команда фронта, есть команда бекенда
Фронт не может сделать полноценную версию без бекенда, поэтому для команды бекенда заказчик — команда фронтенда. Бекенд должен поставить им рабочую API в сроки, заложенные в итерацию. При этом public-интерфейс должен появиться гораздо раньше, потому что фронт-эндщики могут его замокать и тоже начать работу.
Для фронта клиент — отдел тестирования, PM или кто там отвечает за качество. И только после этого проводим демо оунеру. Когда проводим демо заказчик — это заказчик, а разработчик — это вся команда: фронт и бек и qa и pm.
Фронт не может сделать полноценную версию без бекенда, поэтому для команды бекенда заказчик — команда фронтенда. Бекенд должен поставить им рабочую API в сроки, заложенные в итерацию. При этом public-интерфейс должен появиться гораздо раньше, потому что фронт-эндщики могут его замокать и тоже начать работу.
Для фронта клиент — отдел тестирования, PM или кто там отвечает за качество. И только после этого проводим демо оунеру. Когда проводим демо заказчик — это заказчик, а разработчик — это вся команда: фронт и бек и qa и pm.
Если нет, значит руководитель этого проекта плохо донёс до его участников критерии успешности этого самого проекта.
Когда каждый преследует только свои цели и его ни капли не заботит общий результат — это не команда и с построением команды ПМ не справился.
Когда каждый преследует только свои цели и его ни капли не заботит общий результат — это не команда и с построением команды ПМ не справился.
Когда каждый преследует только свои цели и его ни капли не заботит общий результат — это не команда и с построением команды ПМ не справился.Есть принципильно два вида оценки работы — командная и индвидуальная. У каждой как плюсы так и минусы. В командной оценке один разработчик может идеально выполнять свою работу. Но из-за менее эффективных коллег остаться без бонуса. Из практики, очень немногие согласны в такой схеме постоянно работать. Пара факапов — и народ начинает роптать.
А если оценивается работа конкретного исполнителя — то проблема та что вы описали. Остутствие результата.
Если оценивать не командную работу, а индивидуальную, то мы переходим к классическим KPI. Тоже со своими изъянами, подсиживанием, «крысятничеством» и т.п., когда один украл заслуги другого и выдал за свои.
И то, и другое — крайности.
Зачем бросаться в крайности?
Вы ПМ (или РП, как вы себя называете). У вас есть команда. Со своими плюсами и минусами. Вот изучите её и выберите свою правильную только для этой команды систему оценок.
Каждый шагает по отдельности, но никто ведь не смотрит под ноги всю дорогу.
И то, и другое — крайности.
Зачем бросаться в крайности?
Вы ПМ (или РП, как вы себя называете). У вас есть команда. Со своими плюсами и минусами. Вот изучите её и выберите свою правильную только для этой команды систему оценок.
Каждый шагает по отдельности, но никто ведь не смотрит под ноги всю дорогу.
Из личной практики — подавляющее большинство исполнителей не хотят коллективной ответственности. «Я свою работу делаю хорошо» — железобетонный аргумент, с которым не поспоришь.
Вы думаете всякий РП имеет право менять систему KPI разработчиков? Да они могут ему даже не подчиняться напрямую, в матричной оргструктуре.
Да, безусловно у РП есть масса рычагов влияния на команду, и ими надо пользоваться по максимуму. Я много чего перепробовал, могу без лишней скромности сказать что в конце концов стало получаться неплохо. Но многое победить так и не удалось.
PS:
выберите свою правильную только для этой команды систему оценок
Вы думаете всякий РП имеет право менять систему KPI разработчиков? Да они могут ему даже не подчиняться напрямую, в матричной оргструктуре.
Да, безусловно у РП есть масса рычагов влияния на команду, и ими надо пользоваться по максимуму. Я много чего перепробовал, могу без лишней скромности сказать что в конце концов стало получаться неплохо. Но многое победить так и не удалось.
PS:
ПМ (или РП, как вы себя называете)Или PM или РП. ПМ — не совсем корректно. Тем более ПМ — это еще и Product Manager, который совсем не Project Manager
Мало ли, чего они не хотят.
Большинство — интроверты, с людьми работать не умеют и не хотят.
А придётся.
В итоге всё равно один единственный козёл отпущения. Это РП. Заказчик будет спрашивать с вас, а никого другого вы в обиду давать ни в коем случае не должны.
Большинство — интроверты, с людьми работать не умеют и не хотят.
А придётся.
В итоге всё равно один единственный козёл отпущения. Это РП. Заказчик будет спрашивать с вас, а никого другого вы в обиду давать ни в коем случае не должны.
Мало ли, чего они не хотят.Все-таки надо считаться с людьми, именно они всё делают.
В итоге всё равно один единственный козёл отпущения. Это РП. Заказчик будет спрашивать с вас, а никого другого вы в обиду давать ни в коем случае не должны.Ну это само собой. У Заказчика должна быть одна точка входа для любых намерений :)
Но молча прощать факапы команде Рп тоже не имеет права. Иначе будут как безответственные дети.
Про джуниров очень спорно, потому что, иногда части Дрим-Тим тоже сваливают, а не все джуниоры уходят, через полгода (очень от атмосферы зависит).
Как найти работу джуниору и не перегрузить синьоров — это уже менеджерская задача. Кто-то с этим справляется, кто-то нет.
Как найти работу джуниору и не перегрузить синьоров — это уже менеджерская задача. Кто-то с этим справляется, кто-то нет.
4a. Аналитик\архитектор формулируют задачу в терминах сначала бизнес\функциональных требований, затем в виде частного технического задания. Текст задачи уходит в Source Control (Git), задание в Jira и BPM
Пожалуйста, подскажите зачем текст задачи в Git, ведь он есть в Jira? Это отдельный репозитарий от репозитария с исходным кодом?
Требования изначально описываются в ms word, причин для этого на самом деле довольно много:
В Jira задача заводится, часто лишь с кратким описанием, файл с полной постановкой просто прикрепляется.
- нужен формальный документ для отчетности (деньги-задачи)
- текстовый процессор удобней, по крайней мере для аналитиков и бизнеса
- рецензирование удобнее, чем длинная портянка переписки в комментариях в Jira
- для ms word есть clearcase плагин
- есть возможность вкладывать внешние файлы (преимущество спорное ибо порождает спагетти в документации, но привычка — вторая натура)
В Jira задача заводится, часто лишь с кратким описанием, файл с полной постановкой просто прикрепляется.
Word это очень плохо. В первую очередь тем, что невозможно совместное внесение изменений в требования. Согласования превращаются в ад. Т.е. набросать документ — ок. Как система работы с документами — вообще не ок. А ведь согласовавыть нужно на каждом шаге, как с заказчиками, так и с исполнителями.
Как минимум, советую попробовать Confluence, если вам важно форматирование и всякие такие плюшки + у вас уже есть Jira.
Как минимум, советую попробовать Confluence, если вам важно форматирование и всякие такие плюшки + у вас уже есть Jira.
Можно через SkyDrive делать совместное использование файлов ворда. Да и никто не мешает разбить документ на зоны ответственности, чтобы каждый правил свой кусок, а для подписи собирать все воедино.
Confluence уже используется, но преимущественно как база для обмена опытом. Повторюсь, word удобен бизнесу, удобен менеджменту ИТ, т.к. нужны печатные версии для отчетности, word имеет плагин для ClearCase и т.д.
Само же согласование интерактивно, никто не редактирует документы в прямом смысле слова одновременно. Чтобы документ не «потерялся в почте», его выкладывают на портал, откуда забирают на редактирование прямо через интерфейс ms word. Более того, ms word в связке с sharepoint позволяют видеть, кто какие правки вносил и предоставляют возможность удобно мерджить несколько версий документа. Не сочтите за рекламу MS, но это действительно удобно.
Но, уверен, одна из главных причин — бизнес пользователи знают и умеют работать в ворде, заставить их пересесть в Confluence — низовое звено еще пересядет, среднее звено и выше — никогда.
Само же согласование интерактивно, никто не редактирует документы в прямом смысле слова одновременно. Чтобы документ не «потерялся в почте», его выкладывают на портал, откуда забирают на редактирование прямо через интерфейс ms word. Более того, ms word в связке с sharepoint позволяют видеть, кто какие правки вносил и предоставляют возможность удобно мерджить несколько версий документа. Не сочтите за рекламу MS, но это действительно удобно.
Но, уверен, одна из главных причин — бизнес пользователи знают и умеют работать в ворде, заставить их пересесть в Confluence — низовое звено еще пересядет, среднее звено и выше — никогда.
Ситуация с оценкой трудозатрат — просто классика. Я уже давно вывел для себя правило: 15-минутная задача (поменять пару операторов в коде) требует на выполнение минимум двух часов. И это без всяких хитростей вроде «вхождения в поток»: 15 минут на кодинг, а остальное — проверка, отладка, оформление кода, сборка версии (и хорошо, если она собирается за несколько минут). После демонстративного выполнения нескольких таких задач у меня всегда был аргумент в спорах с директором.
А диаграмму вашу читать очень трудно. Я, например, не меньше минуты искал цифру 1. Она бы читалась гораздо легче, если развернуть её по временной оси в диаграмму взаимодействия UML, с «плавательными дорожками» для каждого участника.
А диаграмму вашу читать очень трудно. Я, например, не меньше минуты искал цифру 1. Она бы читалась гораздо легче, если развернуть её по временной оси в диаграмму взаимодействия UML, с «плавательными дорожками» для каждого участника.
Исправьте, пожалуйста «статистический анализ» на «статический анализ». В теме больше шести лет — не могу терпеть :-).
Сознательно не пишу в личку, чтобы другие люди знали, что это разные вещи.
Сознательно не пишу в личку, чтобы другие люди знали, что это разные вещи.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
История тяжелого проекта: немного о бюрократии, инфраструктуре и процессе разработки ПО