Human Resources → Улучшение собственной эффективности: Yaware
Привет, %хабраюзер%!
Часто бывает так, что патологически не хватает времени, или оно есть и надо использовать его с максимальной эффективностью.
Многие умеют правильно мотивировать себя к работе и не давать халявить, но, даже учитывая это, как можно увеличить собственную производительность? Под катом немного про систему учета рабочего времени и улучшения эффективности Yaware.
Часто бывает так, что патологически не хватает времени, или оно есть и надо использовать его с максимальной эффективностью.
Многие умеют правильно мотивировать себя к работе и не давать халявить, но, даже учитывая это, как можно увеличить собственную производительность? Под катом немного про систему учета рабочего времени и улучшения эффективности Yaware.
Agile → 5 причин отказаться от оценок
В нашей компании мы не оцениваем работу. Ни в часах, ни в поинтах, ни в зеленых крокодилах. Совсем не оцениваем. Если вы давно хотели отказаться от оценок, но не знали, почему, вот вам пять причин.
Оценки занимают время. Даже если вы оцениваете в абстрактных поинтах, играя в покер, все равно тратится прилично времени. А что, если вы хотите улучшить точность оценок? Тогда вы собираете данные, анализируете данные и обсуждаете результаты анализа. Все это тоже занимает прилично времени. Но подумайте, вам на самом деле нужны оценки? Часто это waste. Лучше потратить время на что-то действительно полезное для продукта.
1. Вы не будете тратить время на оценки
Оценки занимают время. Даже если вы оцениваете в абстрактных поинтах, играя в покер, все равно тратится прилично времени. А что, если вы хотите улучшить точность оценок? Тогда вы собираете данные, анализируете данные и обсуждаете результаты анализа. Все это тоже занимает прилично времени. Но подумайте, вам на самом деле нужны оценки? Часто это waste. Лучше потратить время на что-то действительно полезное для продукта.
Управление проектами → Два протокола управления проектами
Доброго времени суток.
Я пришел в управление проектами из программирования. То есть, нет так давно, я еще писал код и мне это очень нравилось. Меня мало беспокоили волнения, происходящие где-то на верху — «у менеджеров». Все поменялось в 2004, когда меня назначили тим лидом.
Это был большой и сложный проект. Мы работали как удаленная офшорная группа в постоянной атмосфере прессинга со стороны менеджмента. Оценки задач спускались сверху, и чтобы хоть как-то справиться с задачами, приходилось работать до позднего вечера и по выходным.
Тогда я начал задумываться о причинах такой ситуации, начал читать посты и книги по менеджменту. Как программист, находящийся под впечатлением революционных архитектурных решений — таких, как MVC и паттерны Фоулера, я полагал, что есть *техническое* решение наших проблем с менеджментом — нужно его только отыскать и применить.
Следующие несколько лет я искал *супер фреймворк* для управления проектами. Но только недавно понял, что его нет и быть не может. Проблема заключается в том, что в разработке ПО одновременно используются 2 конфликтующих протокола общения между участниками Процесса.
Сейчас я расскажу о моем текущем видении проблемы, а также опишу одну из возможных стратегий совместного использования этих двух протоколов.
Я пришел в управление проектами из программирования. То есть, нет так давно, я еще писал код и мне это очень нравилось. Меня мало беспокоили волнения, происходящие где-то на верху — «у менеджеров». Все поменялось в 2004, когда меня назначили тим лидом.
Это был большой и сложный проект. Мы работали как удаленная офшорная группа в постоянной атмосфере прессинга со стороны менеджмента. Оценки задач спускались сверху, и чтобы хоть как-то справиться с задачами, приходилось работать до позднего вечера и по выходным.
Тогда я начал задумываться о причинах такой ситуации, начал читать посты и книги по менеджменту. Как программист, находящийся под впечатлением революционных архитектурных решений — таких, как MVC и паттерны Фоулера, я полагал, что есть *техническое* решение наших проблем с менеджментом — нужно его только отыскать и применить.
Следующие несколько лет я искал *супер фреймворк* для управления проектами. Но только недавно понял, что его нет и быть не может. Проблема заключается в том, что в разработке ПО одновременно используются 2 конфликтующих протокола общения между участниками Процесса.
Сейчас я расскажу о моем текущем видении проблемы, а также опишу одну из возможных стратегий совместного использования этих двух протоколов.
Персональные блоги → Очередная выстраданная истина
Программисты постоянно срывают сроки не потому, что медленно работают, а потому, что изначально не могут верно оценить срок. Они свято верят в то, что смогут в определенный момент поднажать и сделать больше чем обычно, и никаких непредвиденных проблем при этом не возникнет.
Веб-разработка → Чего стоит смена интерфейса?
Заказчик хочет изменить дизайн. Допустим, даже уже готова вёрстка. Сколько стоит её натянуть? Ну, по столько-то часов на страницу, и накинем ещё по столько то в уме на риски…
— А что там делать? Всё ведь уже готово! Всего то, вёрстку натянуть — Знакомые слова?
А вот ещё одна фраза, модная среди некоторых «руководителей-теоретиков»:
— Смена дизайна, это не более 30% времени всего проекта!
Вот только почему практика расходится с теорией?
А что вы обычно отвечаете? Я обычно говорю:
— Эмм… Ну… Ведь неизвестно, что именно изменилось, возможно, это затронет не только шаблоны.
Только что-то надоело оправдываться. А давайте попробуем разобраться.
— А что там делать? Всё ведь уже готово! Всего то, вёрстку натянуть — Знакомые слова?
А вот ещё одна фраза, модная среди некоторых «руководителей-теоретиков»:
— Смена дизайна, это не более 30% времени всего проекта!
Вот только почему практика расходится с теорией?
А что вы обычно отвечаете? Я обычно говорю:
— Эмм… Ну… Ведь неизвестно, что именно изменилось, возможно, это затронет не только шаблоны.
Только что-то надоело оправдываться. А давайте попробуем разобраться.
Дизайн в IT → Пример того, как бизнес может быть простым, когда вы его не усложняете
Вчера мне попался на глаза флаер, который лежал у меня перед дверью во дворе:
Я как раз кое-что затеял сделать на заднем дворе. Затея так и не была доведена до ума. Я решил узнать у этих ребят, сколько будет стоить эта работа. Я позвонил им. Через 10 минут пришел парень. Он был неподалеку на другом участке вниз по улице. Мы заглянули на задний двор. Я объяснил, что необходимо сделать. Он посмотрел около двадцати секунд и сказал — 300 $. Я сказал «идет!». Вот оно. Никаких плановых проектов. Никаких «Я сообщу вам завтра». Ничего вроде «Мне нужно прикинуть сколько будут стоить все расходные материалы, я сообщу о цене по почте на следующей неделе».
Просто 300$. Идет! Когда вы могли бы начать? В среду. Сколько времени у вас это займет? Работы на пару часов для нескольких ребят.
Он знает свое дело. Я знаю сколько стоит мое время. Конец сделки.
Это было настолько чертовски освежающе. Я знаю, что абсолютно все может быть сделано таким образом, но часто это все долго тянется по дороге, которая выложена из формальщины с кучей вещей в которых нет необходимости. Раздутые контракты, задержки, красные ленточки, предварительные оценки стоимости основанные на предварительной оценке материала, «дайте мне время подумать об этом и я вам перезвоню» и т. д. Существенно? Иногда да, но в большинстве случае скорее всего нет.
Я как раз кое-что затеял сделать на заднем дворе. Затея так и не была доведена до ума. Я решил узнать у этих ребят, сколько будет стоить эта работа. Я позвонил им. Через 10 минут пришел парень. Он был неподалеку на другом участке вниз по улице. Мы заглянули на задний двор. Я объяснил, что необходимо сделать. Он посмотрел около двадцати секунд и сказал — 300 $. Я сказал «идет!». Вот оно. Никаких плановых проектов. Никаких «Я сообщу вам завтра». Ничего вроде «Мне нужно прикинуть сколько будут стоить все расходные материалы, я сообщу о цене по почте на следующей неделе».
Просто 300$. Идет! Когда вы могли бы начать? В среду. Сколько времени у вас это займет? Работы на пару часов для нескольких ребят.
Он знает свое дело. Я знаю сколько стоит мое время. Конец сделки.
Это было настолько чертовски освежающе. Я знаю, что абсолютно все может быть сделано таким образом, но часто это все долго тянется по дороге, которая выложена из формальщины с кучей вещей в которых нет необходимости. Раздутые контракты, задержки, красные ленточки, предварительные оценки стоимости основанные на предварительной оценке материала, «дайте мне время подумать об этом и я вам перезвоню» и т. д. Существенно? Иногда да, но в большинстве случае скорее всего нет.
Фриланс → Как удачно расчитать цену и время проектов во фрилансе
Одна из самых больших проблем начинающих фрилансеров — оценка стоимости задания.
На самом деле — оценка стоимости проектов — очень не простой момент и очень важно научится правильно оценивать стоимость проекта, что предлагается.
Тот, кто считает, что в этом ошибаются только начинающие — глубоко не прав, ошибкой цены и сроков грешат даже более-менее успешные фрилансеры, а то и профессионалы. Очень часто успех или неудача проекта упираются корнем в изначальную оценку цены и сроков.
Так как же правильно оценить проект?
На самом деле — оценка стоимости проектов — очень не простой момент и очень важно научится правильно оценивать стоимость проекта, что предлагается.
Тот, кто считает, что в этом ошибаются только начинающие — глубоко не прав, ошибкой цены и сроков грешат даже более-менее успешные фрилансеры, а то и профессионалы. Очень часто успех или неудача проекта упираются корнем в изначальную оценку цены и сроков.
Так как же правильно оценить проект?