Имеется отдел у заказчика (20 человек). Документооборот.
Было: 20 человек заключают договора и их обслуживают (принимают корреспонденции по ним, рассылают, организуют документооборот и т.д.). Каждый из них имеет свою коллекцию договоров и таким образом выполняют всю положенную работу по договорам из своего набора («от» и «до»).
Желание заказчика: разделить работу так, чтобы конкретные сотрудники занимались только часть работы (одна часть занимается заключением договоров, вторая часть — их обслуживанием, третья — организацией переметки, четвертая — закрытием).
Таким образом желание бизнеса состоит в том, чтобы работа по договорам стала более операционной (какой она собственно и должна быть).
Бизнес-процесс понятен. Проблем с реализацией бизнес-логики нет.
Заказчик во время реорганизации отдела проводит частичное переформирование штата, обучение сотрудников, переезд в новое здание и т.д.
>Вы уверены, что 150 человек нельзя разбить на 10 маленьких команд?
Вы правда читали «мифический человеко-месяц»? И как это относится к поставленному вопросу?
> Я очень, искренне сочувствую этому проекту.
> Особенно я сочувствую второй группе разработчиков.
> Почему-то мне кажется, что это гос. проект.
> Нет? В нормальном бизнесе такое еще бывает?
Нет. И собственно это был пример того как метрики помагают. Мне больше интересно как бы поступили вы без метрик в данном случае.
p.s. вы не отвечаете на главные вопросы и смысл диалога теряется:
>У нас нет слабых программистов вообще
Как это связано с тем хорошо они работают в команде или нет?
1. Ну т.е. у вас маленькая команда, в которой в принципе можно вообще нормально жить без какой-либо методологии, а так же можно жить с любой из методологии. Тем более когда разрабатываете свой продукт.
Не запутались ли вы в предположении что модифицировав стандартные методы разработки, вы получили прирост в производительности команды? Тем более что вы эту самую производительность никак не измеряете и не можете твердо сказать какой она была и какой стала?
2.
>У нас нет слабых программистов вообще
Как это связано с тем хорошо они работают в команде или нет?
>А как вы узнаете, что ваша команда работает на 100%?
>Мне очень интересно, как метрики вам помогают это делать.
В конкретных ситуациях по-разному.
К примеру, ведется проект. Есть два отдельные группы разработчиков: первая — развивает функционал, вторая — латает выявленные дефекты.
По накопленной статистике видно что количество выявляемых ошибок растет быстрее чем количество исправляемых. Отсюда делаем вывод что надо усиливать вторую команду засчет первой.
Производительность Команды увеличивается.
Уверен. Все что описано выше — отношения уровня «менеджер-команда».
Мнением и потребностями бизнеса тут не пахнет. IT в бизнесе — это сервис.
Пример.
Абстрактная ситуация, которая проецируется на большое число проектов для бизнеса:
Живет компания. Затеяли реорганизацию, направленную на оптимизацию бизнес-процессов. К концу реорганизации (due time) нужна новая erp-система. Ищут подрядчика. Приходят к вам.
Ваши действия?
1. Сколько человек у вас в команде (сколько программистов, сколько тестеров, сколько аналитиков и т.д.)?
2. Каким образом вы оцениваете эффективность своей команды? И если вы ее не оцениваете, то как вы узнаете что ваша команда работает на все сто процентов, на которые она может?
1. Какого размера у вас команды и какого масштабы проекты? (Просто кажется я начал догадываться к какой классификации по книжке «мифический человеко-месяц» вы относитесь. Хочу проверить).
2. Всяческие отчетности и метрические показатели при правильном использовании по ходу развития большого проекта помогают существенно оптимизировать процесс разработки. Как вы обходитесь без них?
Не думаю что это реалистично чтобы компании (в среднем) начали выбирать себе клиентов.
Особенно компании, которые занимаются разработкой, скажем, не сайтиков, а медицинского оборудования или любого другого специфического софта.
Я всегда думал что команда по большей части подстраивается под заказчика.
p.s.
> Наша компания делает свой продукт. Я никогда не работал на заказ по аджайл схемам.
В таком случае думаю вам стоит указать это в посте. Иначе весь текст теряет смысл.
Данные методы использовались в фашисткой Японии, когда пленным американцам разрешалось написать письмо на родину если они победят в конкурсе лучшего сочинения на тему почему им хорошо в концлагере и почему режим такой замечательный.
Потому «призы» становились все менее значимыми: пара сигарет и пр.
Таким образом уже никто не мог оправдать себя тем что цель оправдывала средства.
А метод прост как дрова: когда человек что-то пишет или высказывает какую-то идею, он сам того не замечая, начинает в нее верить.
Так что привет всем конкурсам а-ля «Готовьте вместе с галиной бланкой» и «Биг Мак — не устоять никак».
P.S. главным результатом конкурса для организаторов является никак не креативность, а кол-во народа, принявшего участие.
>Vupen рекомендует всем пользователям IE выключить JavaScript или использовать другой браузер,
>не подверженный данной уязвимости.
Ну да, иначе новый Rustock не заставит себя долго ждать.
Самое интересное, что майкрософт отрапартовала о закрытии ботнета, при этом сама же по сути и являлась его причиной.
Так, самое интересное забыли написать. Что это за «массовая sql-инъекция», которая «заражает» 500 тысяч сайтов. И как sql-инъекция связана со скриптами?
Складывается ощущение, что в ФБ работает хамло. Во всяком случае это далеко не первый случай когда они что-то удаляют, при этом не то что не поинтересовавшись, но и даже не объяснив причины.
Было: 20 человек заключают договора и их обслуживают (принимают корреспонденции по ним, рассылают, организуют документооборот и т.д.). Каждый из них имеет свою коллекцию договоров и таким образом выполняют всю положенную работу по договорам из своего набора («от» и «до»).
Желание заказчика: разделить работу так, чтобы конкретные сотрудники занимались только часть работы (одна часть занимается заключением договоров, вторая часть — их обслуживанием, третья — организацией переметки, четвертая — закрытием).
Таким образом желание бизнеса состоит в том, чтобы работа по договорам стала более операционной (какой она собственно и должна быть).
Бизнес-процесс понятен. Проблем с реализацией бизнес-логики нет.
Заказчик во время реорганизации отдела проводит частичное переформирование штата, обучение сотрудников, переезд в новое здание и т.д.
Вы правда читали «мифический человеко-месяц»? И как это относится к поставленному вопросу?
> Я очень, искренне сочувствую этому проекту.
> Особенно я сочувствую второй группе разработчиков.
> Почему-то мне кажется, что это гос. проект.
> Нет? В нормальном бизнесе такое еще бывает?
Нет. И собственно это был пример того как метрики помагают. Мне больше интересно как бы поступили вы без метрик в данном случае.
p.s. вы не отвечаете на главные вопросы и смысл диалога теряется:
>У нас нет слабых программистов вообще
Как это связано с тем хорошо они работают в команде или нет?
Не запутались ли вы в предположении что модифицировав стандартные методы разработки, вы получили прирост в производительности команды? Тем более что вы эту самую производительность никак не измеряете и не можете твердо сказать какой она была и какой стала?
2.
>У нас нет слабых программистов вообще
Как это связано с тем хорошо они работают в команде или нет?
>А как вы узнаете, что ваша команда работает на 100%?
>Мне очень интересно, как метрики вам помогают это делать.
В конкретных ситуациях по-разному.
К примеру, ведется проект. Есть два отдельные группы разработчиков: первая — развивает функционал, вторая — латает выявленные дефекты.
По накопленной статистике видно что количество выявляемых ошибок растет быстрее чем количество исправляемых. Отсюда делаем вывод что надо усиливать вторую команду засчет первой.
Производительность Команды увеличивается.
Мнением и потребностями бизнеса тут не пахнет. IT в бизнесе — это сервис.
Пример.
Абстрактная ситуация, которая проецируется на большое число проектов для бизнеса:
Живет компания. Затеяли реорганизацию, направленную на оптимизацию бизнес-процессов. К концу реорганизации (due time) нужна новая erp-система. Ищут подрядчика. Приходят к вам.
Ваши действия?
2. Каким образом вы оцениваете эффективность своей команды? И если вы ее не оцениваете, то как вы узнаете что ваша команда работает на все сто процентов, на которые она может?
1. Какого размера у вас команды и какого масштабы проекты? (Просто кажется я начал догадываться к какой классификации по книжке «мифический человеко-месяц» вы относитесь. Хочу проверить).
2. Всяческие отчетности и метрические показатели при правильном использовании по ходу развития большого проекта помогают существенно оптимизировать процесс разработки. Как вы обходитесь без них?
Особенно компании, которые занимаются разработкой, скажем, не сайтиков, а медицинского оборудования или любого другого специфического софта.
Я всегда думал что команда по большей части подстраивается под заказчика.
p.s.
> Наша компания делает свой продукт. Я никогда не работал на заказ по аджайл схемам.
В таком случае думаю вам стоит указать это в посте. Иначе весь текст теряет смысл.
Он говорит: «Оккей, вижу вы ребята толковые. Сколько вам нужно времени что сделать эту работу?».
Ваши действия?
Потому «призы» становились все менее значимыми: пара сигарет и пр.
Таким образом уже никто не мог оправдать себя тем что цель оправдывала средства.
А метод прост как дрова: когда человек что-то пишет или высказывает какую-то идею, он сам того не замечая, начинает в нее верить.
Так что привет всем конкурсам а-ля «Готовьте вместе с галиной бланкой» и «Биг Мак — не устоять никак».
P.S. главным результатом конкурса для организаторов является никак не креативность, а кол-во народа, принявшего участие.
>не подверженный данной уязвимости.
Ну да, иначе новый Rustock не заставит себя долго ждать.
Самое интересное, что майкрософт отрапартовала о закрытии ботнета, при этом сама же по сути и являлась его причиной.
Странно но не на яху, ни на cnn ничего описательного нету.
Аналогия понятна?