Во вас зацепило-то!
Вы слишком много значения приаёте фразе «Работаем на Результат».
На самом деле эту фразу надо пропускать мимо ушей, если только вы не заказчик.
Логично, вы ведь не скажете заказчику, что на самом деле лишь 20% усилий затрачиваете на результат, а остальные 80% на процесс. Ему не важно, как вы получили результат. Менделеев вот утверждает, что ему во сне всё приснилось. Ну, а что? Результат-то более чем. По крайней мере, всех устроил.
Когда вы покупаете телефон, вы же не интересуетесь именами китайских рабочих, благодаря которым вы ежедневно пользуетесь данным устройством. Вам не интересно, чем они обычно обедают, и что, возможно, если бы в столовой им клали не две, а четыре ложки риса (т.е. в 2 раза больше), то производительность подскочила бы в 3 раза и количество брака существенно снизилось бы. Вам всё это не интересно, вам нужен результат — те-ле-фон. И эти китайские рабочие именно на него и работают. Вас устраивает ваш телефон? Если купили и пользуетесь, значит, устраивает.
Вот и говорят заказчикам ровно то, что они хотят услышать.
Понятно же, что всё на самом деле взаимосвязано. Просто это бывает не интересно и не стоит озвучивать.
Другое дело, если у заказчика с вами длительные отношения. Вот тогда заказчику становится интересен и процесс тоже (если заказчик не самодур и мазохист, что тоже не редкость).
Кроме того, сам «результат» можно трактовать по-разному. Например, улучшение процесса — отличный результат. Особенно, если у вас действительно есть этот процесс.
Я имел в виду, что в реальности приходится сталкиваться с такими проектами, когда невозможно внятно разбить его на задачи, оценить сложность, пока сама задача не будет доведена до определённого этапа. Это вполне логично, но попробуйте объяснить это заказчику, к которому вы пришли и рассказываете, что на его деньги занимались исследованием и пришли к отрицательному результату. В результате субъективно под заказчика придётся подстраиваться.
Далее, для оценки трудозатрат приходится пользоваться определёнными моделями. Все эти модели опираются на вполне определённую статистику и подразумевают большое количество участников проекта. Именно тогда субъективные факторы (плохое настроение ведущего инженера в прошлую пятницу, свадьба шурина системного архитектора и т.п.) взаимоуничтожатся, попав под статистическое усреднение. Останутся только объективные факторы.
Но если у вас участников проекта мало (а таких проектов подавляющее большинство), тогда при применении какой-либо модели субъективные факторы буду вполне соизмеримыми с объективными факторами. И приходится уже учитывать их тоже. Например, ведущий инженер по понедельникам и четвергам не может задержаться на работе, потому что у него по этим дням тренировка, но обычно он с радостью задерживается. Или производительность системного архитектора после выходных ниже, чем в среду, но выше, чем в пятницу.
Да опять-таки ни причём здесь Scrum.
Ни одна из существующих методологий не способна это учесть и не возможно это вообще под какие-либо универсальные рамки подогнать.
Это иррационально, субъективно, и ваша роль как руководителя (команды или самого себя) просто пронаблюдать такие вещи и вывести субъективные закономерности.
Если изначально всё детально разбито на операции, то какая к чёрту разница, как вы дальше будете решать эту задачу.
Про жонглирование — это не к вам и не к автору. Я всё-таки с вами не знаком, чтобы делать такие сильные утверждения. Я скорее про наблюдаемую тенденцию, между делом.
Набор практик — это хорошо, хотя именно это и пугает, потому что многие читают не «набор практик», а «всегда удачный и везде применимый набор практик». Но если кто-то утверждает, что эти практики хорошо применились в конкретной компании на конкретном проекте с конкретной командой, то прежде всего встаёт вопрос не в том, удачны практики или нет, а в сопоставлении вашего конкретного проекта с тем самым проектом, где эти практики удачно применились. А с этим как раз проблемы, потому что помимо каких-то субъективных параметров для сопоставления нужны прежде всего объективные параметры. Которые никто не знает как оценивать либо их просто крайне затруднительно оценить для конкретного проекта. Т.е., к примеру, вам привели в пример проект, в котором здорово применяются определённые практики, и параметры проекта вам выданы… в килограммах. Вы пытаете оценить свой проект на применимость этих практик и получаетете оценку… в метрах. Вот и думайте потом, как сопоставить эти килограммы с вашими метрами. Кто-то из авторов, возможно, приведёт вам эмпирически выведенный коэффициент для конвертации килограммов в метры, но этот коэффициент рассчитан по сотням компаний с командами в 30-100 человек. А у вас всего лишь 5 человек в команде. И вы применяете этот коэффициент. И справедливо получаете ошибку в 200%. И проект ваш разлетается в щепки.
Scrum вполне приемлет оценки. Другое дело, что не так часто авторы упоминают о такой необходимости, и читатель как бы подразумевает, что обойдётся безо всяких измерений. Измерить можно что угодно и измерять надо. Вопрос лишь в том, как это сделать. Для получения системы оценок в компании руководства и заказчики должны с пониманием относиться к этому. Потому что главный бонус, который можно получить на выхлопе — это стабильность, повторяемость результата. Но в подавляющем большинстве случаев людям не нужна какая-то повторяемость, стабильность, нужен лишь сиюминутный результат, а там хоть трава не расти. С новым проектом начнём с самого начала. И так по кругу. В результате редкий руководитель владеет такими знаниями и совсем редко такие знания оседают в базах знаний компаний.
Для ИТ в целом это очень больная тема. И Scrum как таковой тут ни причём.
Очень многие авторы предлагают определённые способы, но далеко не все из них применимы в принципе и ни одна не применима в чистом виде. А учитывая то, что все без исключения авторы почему-то не приводят примеров сложнее и реальнее, чем «Hello, World!», то на выходе получается едва ли не бесполезная информация.
Я уже молчу о том, что в очень многих случаях статьи об этом — банальное жонглирование модными терминами с непонятной целью.
Зачастую компании и команды внутри них организованы таким образом, что затруднительно оценивать что-либо — будь то сложность проекта, его сроки, бюджет. И так же сложно осуществлять мониторинг и прогнозирование. Большинство умозаключений, которые можно сделать в ходе наблюдения за проектом, являются довольно хрупкими закономерностями, которые очень сильно зависят от слишком большого количества переменных. Более того, многие проекты или компании малы, так что вообще какие-либо закономерности и тренды выявлять опасно, т.к. для команды из пары тройки разработчиков в проекте на 3-4 месяца ошибка оценки можен переваливать за 200%, что никуда не годится. Я к тому, что всё настолько иднивидуально, что рецепт, успешно применяемый в условном IBM, скорее всего не сработает в фирме «Рога и Копыта» с персоналом 20 человек вместе с уборщицей.
Я не говорю, что этим не надо заниматься. Напротив: следует всегда держать руку на пульсе. Но следует больше пользоваться головой и руководствоваться здравым смыслом, нежели упражняться в склонении новомодных терминов. В данном случае Scrum ни причём совершенно.
На гонконгском Sonystyle сабж вместе с внешним аккумулятором на 4000 MAH и плёнкой для экрана стоит HK$4,398.00. На наши деньги приблизительно 17500 руб. А у нас «голый» 25000 руб. Это что-то немыслимое!
Мда.
Помню, очередной Cube отсутствием некоторых критичных мелочей меня настолько разочаровал, что я им в сердцах целое гневное письмо написал. Ответили, мол, учтём в будущем. Сомневаюсь.
Одним из пунктов письма было как раз отсутствие внутреннего 3G-модуля.
Хвастливо написано, мол, поддерживаются внешние модемы.
Этим можно было хвастаться, если бы эти модемы были размером (с чем бы сравнить) чуть больше сим-карты.
Но вставлять в компактное мобильное устройство модем размером с четверть самого устройства и считать это достоинством — это ни в какие ворота не лезет. И уж точно не лезет в сумку или в бардачок автомобиля. А если и влезет, то есть крайне высокая вероятность достать это потом с отломанным USB-портом.
У них одинаковое только название: планшет.
Всё остальное — разное. Начиная с технических характеристик и заканчивая целевой аудиторией.
И нет смысла здесь сравнивать габариты. Разве что mail.ru решила перейти от метрической системы к измерению всего и вся «айпадами».
Так и представляю навигатор от mail.ru: «Двигайтесь прямо 800 айпадов, затем держитесь левее».
Нет, я понимаю, что писатели mail.ru обожают Apple и продукцию всех остальных производителей сравнивают именно с их продукцией.
Но сравнивать MS Surface Pro с iPad — надо быть полным кретином.
У Lumia 920 2000 мАч — и не кирпич вроде. Толщина такая же — 10,7 мм.
Это примерно на 14% больше ёмкость.
Если верить техническим характеристикам, несложно прикинуть, что время автономной работы в режиме ожидания в сети 2g/3g будет уже не до 300/400 часов, а до 342/456 часов.
Время в режиме разговора уже не до 7, а до 8 часов.
В режиме плеера не до 18 часов, а до 20,5 часов.
Появятся реальные цифры по времени автономной работы в «смешанном» режиме — можно будет и это оценить.
Но даже так видно, что разница ощутимая.
Пусть будет толще на миллиметр-полтора, но дайте больше ёмкости.
И характеристики отличаются от тех, что на сайте. Например, ёмкость аккумулятора, модель стереогарнитуры.
И смущает одинаковое время работы в 2G- и 3G-сетях в режиме разговора.
И снова аккумулятор не айс…
И память в 8 Гб — это как-то маловато, особенно учитывая стоимость девайса.
А сколько реально доступной для пользователя памяти?
Вы слишком много значения приаёте фразе «Работаем на Результат».
На самом деле эту фразу надо пропускать мимо ушей, если только вы не заказчик.
Логично, вы ведь не скажете заказчику, что на самом деле лишь 20% усилий затрачиваете на результат, а остальные 80% на процесс. Ему не важно, как вы получили результат. Менделеев вот утверждает, что ему во сне всё приснилось. Ну, а что? Результат-то более чем. По крайней мере, всех устроил.
Когда вы покупаете телефон, вы же не интересуетесь именами китайских рабочих, благодаря которым вы ежедневно пользуетесь данным устройством. Вам не интересно, чем они обычно обедают, и что, возможно, если бы в столовой им клали не две, а четыре ложки риса (т.е. в 2 раза больше), то производительность подскочила бы в 3 раза и количество брака существенно снизилось бы. Вам всё это не интересно, вам нужен результат — те-ле-фон. И эти китайские рабочие именно на него и работают. Вас устраивает ваш телефон? Если купили и пользуетесь, значит, устраивает.
Вот и говорят заказчикам ровно то, что они хотят услышать.
Понятно же, что всё на самом деле взаимосвязано. Просто это бывает не интересно и не стоит озвучивать.
Другое дело, если у заказчика с вами длительные отношения. Вот тогда заказчику становится интересен и процесс тоже (если заказчик не самодур и мазохист, что тоже не редкость).
Кроме того, сам «результат» можно трактовать по-разному. Например, улучшение процесса — отличный результат. Особенно, если у вас действительно есть этот процесс.
Но в долгосрочной перспективе это почти всегда выходит дороже.
Далее, для оценки трудозатрат приходится пользоваться определёнными моделями. Все эти модели опираются на вполне определённую статистику и подразумевают большое количество участников проекта. Именно тогда субъективные факторы (плохое настроение ведущего инженера в прошлую пятницу, свадьба шурина системного архитектора и т.п.) взаимоуничтожатся, попав под статистическое усреднение. Останутся только объективные факторы.
Но если у вас участников проекта мало (а таких проектов подавляющее большинство), тогда при применении какой-либо модели субъективные факторы буду вполне соизмеримыми с объективными факторами. И приходится уже учитывать их тоже. Например, ведущий инженер по понедельникам и четвергам не может задержаться на работе, потому что у него по этим дням тренировка, но обычно он с радостью задерживается. Или производительность системного архитектора после выходных ниже, чем в среду, но выше, чем в пятницу.
Ни одна из существующих методологий не способна это учесть и не возможно это вообще под какие-либо универсальные рамки подогнать.
Это иррационально, субъективно, и ваша роль как руководителя (команды или самого себя) просто пронаблюдать такие вещи и вывести субъективные закономерности.
Если изначально всё детально разбито на операции, то какая к чёрту разница, как вы дальше будете решать эту задачу.
Набор практик — это хорошо, хотя именно это и пугает, потому что многие читают не «набор практик», а «всегда удачный и везде применимый набор практик». Но если кто-то утверждает, что эти практики хорошо применились в конкретной компании на конкретном проекте с конкретной командой, то прежде всего встаёт вопрос не в том, удачны практики или нет, а в сопоставлении вашего конкретного проекта с тем самым проектом, где эти практики удачно применились. А с этим как раз проблемы, потому что помимо каких-то субъективных параметров для сопоставления нужны прежде всего объективные параметры. Которые никто не знает как оценивать либо их просто крайне затруднительно оценить для конкретного проекта. Т.е., к примеру, вам привели в пример проект, в котором здорово применяются определённые практики, и параметры проекта вам выданы… в килограммах. Вы пытаете оценить свой проект на применимость этих практик и получаетете оценку… в метрах. Вот и думайте потом, как сопоставить эти килограммы с вашими метрами. Кто-то из авторов, возможно, приведёт вам эмпирически выведенный коэффициент для конвертации килограммов в метры, но этот коэффициент рассчитан по сотням компаний с командами в 30-100 человек. А у вас всего лишь 5 человек в команде. И вы применяете этот коэффициент. И справедливо получаете ошибку в 200%. И проект ваш разлетается в щепки.
Scrum вполне приемлет оценки. Другое дело, что не так часто авторы упоминают о такой необходимости, и читатель как бы подразумевает, что обойдётся безо всяких измерений. Измерить можно что угодно и измерять надо. Вопрос лишь в том, как это сделать. Для получения системы оценок в компании руководства и заказчики должны с пониманием относиться к этому. Потому что главный бонус, который можно получить на выхлопе — это стабильность, повторяемость результата. Но в подавляющем большинстве случаев людям не нужна какая-то повторяемость, стабильность, нужен лишь сиюминутный результат, а там хоть трава не расти. С новым проектом начнём с самого начала. И так по кругу. В результате редкий руководитель владеет такими знаниями и совсем редко такие знания оседают в базах знаний компаний.
Очень многие авторы предлагают определённые способы, но далеко не все из них применимы в принципе и ни одна не применима в чистом виде. А учитывая то, что все без исключения авторы почему-то не приводят примеров сложнее и реальнее, чем «Hello, World!», то на выходе получается едва ли не бесполезная информация.
Я уже молчу о том, что в очень многих случаях статьи об этом — банальное жонглирование модными терминами с непонятной целью.
Зачастую компании и команды внутри них организованы таким образом, что затруднительно оценивать что-либо — будь то сложность проекта, его сроки, бюджет. И так же сложно осуществлять мониторинг и прогнозирование. Большинство умозаключений, которые можно сделать в ходе наблюдения за проектом, являются довольно хрупкими закономерностями, которые очень сильно зависят от слишком большого количества переменных. Более того, многие проекты или компании малы, так что вообще какие-либо закономерности и тренды выявлять опасно, т.к. для команды из пары тройки разработчиков в проекте на 3-4 месяца ошибка оценки можен переваливать за 200%, что никуда не годится. Я к тому, что всё настолько иднивидуально, что рецепт, успешно применяемый в условном IBM, скорее всего не сработает в фирме «Рога и Копыта» с персоналом 20 человек вместе с уборщицей.
Я не говорю, что этим не надо заниматься. Напротив: следует всегда держать руку на пульсе. Но следует больше пользоваться головой и руководствоваться здравым смыслом, нежели упражняться в склонении новомодных терминов. В данном случае Scrum ни причём совершенно.
Помню, очередной Cube отсутствием некоторых критичных мелочей меня настолько разочаровал, что я им в сердцах целое гневное письмо написал. Ответили, мол, учтём в будущем. Сомневаюсь.
Одним из пунктов письма было как раз отсутствие внутреннего 3G-модуля.
Хвастливо написано, мол, поддерживаются внешние модемы.
Этим можно было хвастаться, если бы эти модемы были размером (с чем бы сравнить) чуть больше сим-карты.
Но вставлять в компактное мобильное устройство модем размером с четверть самого устройства и считать это достоинством — это ни в какие ворота не лезет. И уж точно не лезет в сумку или в бардачок автомобиля. А если и влезет, то есть крайне высокая вероятность достать это потом с отломанным USB-портом.
Всё остальное — разное. Начиная с технических характеристик и заканчивая целевой аудиторией.
И нет смысла здесь сравнивать габариты. Разве что mail.ru решила перейти от метрической системы к измерению всего и вся «айпадами».
Так и представляю навигатор от mail.ru: «Двигайтесь прямо 800 айпадов, затем держитесь левее».
Например, iPad также меньше суперкомпьютера. Сравнили. И что?
Как можно сравнивать принципиально разные устройства? Не знаю, всё равно что подзорную трубу с микроскопом сравнивать.
Я не защищаю Майкрософт. В данном случае лично мне действительно непонятно, на какие задачи ориентировано устройство и для кого предназначено.
Но сравнивать MS Surface Pro с iPad — надо быть полным кретином.
Это самый что ни на есть флагман. Наряду с TX. Очень дорогой флагман.
Это примерно на 14% больше ёмкость.
Если верить техническим характеристикам, несложно прикинуть, что время автономной работы в режиме ожидания в сети 2g/3g будет уже не до 300/400 часов, а до 342/456 часов.
Время в режиме разговора уже не до 7, а до 8 часов.
В режиме плеера не до 18 часов, а до 20,5 часов.
Появятся реальные цифры по времени автономной работы в «смешанном» режиме — можно будет и это оценить.
Но даже так видно, что разница ощутимая.
Пусть будет толще на миллиметр-полтора, но дайте больше ёмкости.
И смущает одинаковое время работы в 2G- и 3G-сетях в режиме разговора.
И память в 8 Гб — это как-то маловато, особенно учитывая стоимость девайса.
А сколько реально доступной для пользователя памяти?