Быть может у вас тоже получается сделать меньше, чем хотелось бы. Когда кругом бесконечное количество возможностей, так сложно реализовать одну идею до конца и не переключиться на что-то более интересное. Так много желаний и так мало времени, как же успеть реализовать все что хочется? Попробуйте следовать этим простым правилам:

технику Помидор - вы удивитесь как много можно сделать за 15 минут, если не отвлекаться.

2. Публично объявляйте дату завершения.

Если вы пишите книгу или заканчивайте проект, то было бы не плохо публично заявить о дате релиза. Порой нет ничего более мотивирующего, чем публичное обещание и конечный срок.

3. Давайте себе немного больше времени чем нужно.

Когда вы определите крайний срок для какого-нибудь дела, то добавьте еще чуть-чуть времени. Люди болеют, компьютеры ломаются, а соседи то и дело начинают очередной ремонт... Забронируйте время на непредвиденные обстоятельства, и сохраните себе кучу нервов :)

4. Устанавливайте вехи.

Разбивайте большие проекты на этапы - это позволит сконцентрироваться на ближайших действиях. Сложно стать художником, но не трудно купить краски или найти подходящие курсы. Набросайте основные этапы достижения цели и придерживайтесь установленных сроков.

5. Отдыхайте.

Фанатзим дает не большой прирост к эффективности, но потом обязательно наступает усталость... Хорошим тоном будет планирование не только работы, но и отдыха. Постарайтесь выделять себе время на ничегонеделание и полноценный сон.

Тэги: мотивация, тайм-менеджмент, управление
Постоянная ссылка

Прекрасная книга от руководителей компании Мосигра. Если и существуют лайфаки для российских предпринимателей, то в этой книге вы найдете значительную часть. Авторы делятся опытом и рассказывают какие ошибки они совершали при открытии и управлении Мосигры.

Я насчитал 147 советов или рекомендаций. Редко какой совет занимает больше одного листа. В результате создается впечатление, что авторы заставили работать каждую букву.

Дмитрий Потапенко, а авторы рассказывают как произвести необходимые расчеты. Они помогут спрогнозировать число Клиентов еще ДО снятия аренды помещения.

В четвертой части даются советы по продвижению товара и выстраиванию долговременных отношений с Клиентами. Сами авторы дают такое определение этого слова – формирования таких товара, продажи и постпродажных отношений, которые приносят вам максимальную прибыль.

Мне понравился совет про тренировку менеджеров по продажам с помощью игр:

" Один из первых навыков – способность убеждать, влиять на людей и отстаивать точку зрения. Можно начать играть каждые выходные в мафию, "Сопротивление" или "За бортом!"

Про переговры здесь много полезных советов, но самый важный мне кажется вот этот:

"Вы не должны договориться в результате. Вам не нужны компромиссы, странные пути решения и долгие разговоры. Если условия вас не устраивают, то стоит встать и уйти.
Общий принцип прост: если вы видите, что с вами общаются "чудаки на букву м", то лучше с ними не работать. Даже если проект сулит вам золотые горы. Ставьте на людей.

О качестве издания: твердый переплет, закладка, плотная бумага теплого бежевого цвета и приятный шрифт. В итоге комфортно читать, листать да и не стыдно подарить.

Книга получилась емкой, полезной и мотивирующей на результат. Мне кажется, с настольныи играми авторы научились делать и настольные книги. Эту книгу стоит перечитывать снова и снова.

Купить на Озоне. Книга "Бизнес как игра" Сергей Абдульманов

Скачать с ЛитРес. Книга "Бизнес как игра" Сергей Абдульманов

---

Тэги: геймификация, книги, менеджмент, миф, переговоры, управление
Постоянная ссылка

Помните фильм "Вечного сияния чистого разума" ? В нем Джим Кери хочет удалить свои воспоминания о своей возлюбленной и обращается в соответствующую организацию, которая стирает воспоминания за деньги. Джим засыпал с особым устройством у себя на голове и все что нужно было стереть - отделялось от того, что нужно оставить.

Видимо в фильме режиссер имел в виду то, что наши воспоминания как-то кодируются в образы. В этом подходе есть определенный смысл: воспоминания сокращены и сильно сжаты, что позволяет мозгу хранить их, однако точного воспроизведения при вспоминании не получается (сами попробуйте вспомнить свой прошлый удачный день во всех подробностях).

Воспоминание визуальной сцены чем-то похоже на то, как мозг реагирует, когда вы впервые видите эту сцену, и вроде бы если понять какие связи при этом активизируются, то  их можно разомкнуть. Интересно, но исследования в этой области подтверждают данную гипотезу.
Римской комнаты. Эта техника позволяет запоминать большие объемы информации и по необходимости "забывать" их. Попробуйте использовать эту технику когда вам нужно будет говорить длинную речь, или при изучении стихотворения.
Чернов Дмитрий© chernov.pro

Тэги: мозг, мышление, наука, память
Постоянная ссылка

Первую книгу о менеджменте я прочитал 8 лет назад, и это была книга Ицхак Адизеса. Его теория об управлении очень популярна и. В этом обзоре я постараюсь донести главную идею и поделиться мыслями на этот счет.

Сразу стоит сказать, что книга представляет собой сборник ранних публикаций автора. В ней собраны материалы из прошлых книг и популярных постов блога. То есть кардинально новой модели управления и сдвига парадигмы в ней нет. К тому же, если вы не читали его прошлых книг, то я считаю, что будет достаточно познакомиться только с этой.

Ключевой подход автора в управлении заключается в том, что для эффективного управления организацией в ней должны выполняться четыре базовых роли (PAEI): Produce, Administration, Entrepreneur и Integration.
на Озоне. Скачать в ЛитРес

---

Тэги: книги, менеджмент, миф, управление
Постоянная ссылка

Бережливое производство – это концепция управления производством, основанная на сокращении различного рода потерь. Впервые принципы бережливого производства были разработаны японской компанией Toyota в начале 1990х годов.

В этой книге авторы рассказывают, как компании занятые разработкой программного обеспечения могут оптимизировать свои технологические процессы.

Семь принципов бережливого подхода в разработке ПО

Принцип 1. Ликвидировать потери

Все, что мы делаем, если это не работает на то чтобы наиболее полным образом удовлетворить требования заказчика, является источником непроизводительных затрат. Сюда же можно отнести любую задержку выполнения заказа

В первую очередь авторы рекомендуют сократить потери на исправление уже выполненной работы. Самый яркий пример – тот случай, когда Клиент просит внести изменения в уже утвержденное Техническое Задание или Макеты Дизайна. Если подобные вещи происходят, значит вы выбрали слишком большой цикл разработки. Возможные пути решения:

1. Разбивать разработку всего продукта на короткие итерации (1-3 месяца).
2. Писать документацию не на весь продукт, а только на ближайшую итерацию, чтобы бизнес Клиента не успел измениться.
3. Создавать меньше программного кода. Следует жестко ограничивать функциональные возможности релиза и в первую очередь делать лишь те, которые абсолютно необходимы для бизнеса Клиента.
4. Сократить число случаев, когда работа передается другому лицу (или коллективу).
5. Использовать многофункциональные коллективы, в которых люди могли бы учиться друг у друга.
6. Где возможно – заменить передачу знания через документацию очными обсуждениями, непосредственным наблюдением, а также работой с макетами, прототипами и имитаторами.
7. Выпускать созданные продукты заблаговременно (и частично готовыми) заказчикам для ознакомления и организации с ними обратной связи – так быстро, как это возможно, и так часто, как это практично

Целесообразно сначала полностью разработать 20% программного кода, которые обеспечивали бы 80% потребностей заказчика, и только после этого переходить к разработке следующих наиболее необходимых функциональных возможностей. Не следует заранее составлять список всех возможностей, которые могут когда-либо понадобиться, особенно если этот список исходит от заказчиков, которые не очень хорошо знают, что им нужно.

Принцип 2. Встраивать качество

Процесс разработки следует выстраивать так, чтобы дефекты просто не попадали в код. Если на этапе тестирования выявляется много ошибок (багов), то это означает, что тестирование производится слишком редко.  Дефекты во время финального тестирования должны стать редкостью, а не нормой.

С точки зрения бережливого производства не должно быть очереди дефектов на исправление. Ошибки должны исправляться в тот же момент, когда они обнаруживаются.

Сегодня существуют средства, позволяющие устранять дефекты из программного кода в ходе его создания. Группа разработчиков, используя разработку через тестирование (test driven development), создает блочные тесты и приемочные тесты до создания соответствующего кода.

Разработчики интегрируют код и тесты в систему так часто, как это возможно (каждый час или около того) и инициируют запуск тестовой нагрузки (test harness), чтобы убедиться, что со времени предыдущей проверки дефекты в коде не появились. Если тест не выполняется, они не создают новый код, пока проблема не будет устранена. В конце дня запускается более сложная и полная тестовая нагрузка. В конце недели система проверяется с помощью еще более сложной тестовой нагрузки.

В организациях, где используется такой подход, дефекты возникают редко и их причины устраняются очень быстро.

Принцип 3. Создавать знание

Недостаток "водопадной" модели разработки заключается в том, что архитектура будущего продукта создается заранее и часто совсем не теми людьми, которые будут заниматься непосредственно разработкой. Однако достоинства и недостатки этой архитектуры будут обнаружены после реализации.

При таком подходе невозможно учесть всей сложности, с которой придется столкнуться в ходе разработки. Также проблематично будет вносить пожелания от Клиента или Пользователей продукта, во время обратной связи.

Некоторые полагают, что если мы ‘‘документируем’’ то, что узнали в процессе итеративной разработки (т.е. записываем принятые решения; объясняем, почему они приняты, и перечисляем, что мы узнали нового), то создаем материал, который может быть использован в данной организации для обучения коллег. Однако, скорее всего, эти кипы документации будут просто собирать пыль

Процесс разработки, направленный на создание знания, предполагает, что архитектура программного обеспечения возникнет во время создания программного кода, и исключает затраты на его предварительное определение.

В книге предлагается четыре подхода:

1. Ранний релиз с минимумом функциональных возможностей с тем, чтобы потребители могли его оценить и выразить свое мнение, пожелания и претензии.
2. Ежедневный выпуск сборок, их тестирование и учет (в дальнейшей разработке) результатов тестирования.
3. Наличие коллектива и (или) лидера с достаточным опытом и развитой интуицией, позволяющих принимать правильные решения.
4. Использование модульной архитектуры, поддерживающей возможность добавления новых функций.

Принцип 4. Откладывать необратимые решения

Идея заключается в том, что принятие необратимого решения должно откладывать до последнего момента, но прежде, чем будет слишком поздно. Это позволит набрать максимум доступной информации и сделать обдуманное действие.

Не следует поддаваться мифу, что планирование – это то же, что и принятие обязательств. Планировать следует тщательно, а брать обязательства осторожно. Реальность всегда расходится с первоначальным планом и решения в условиях изменившихся обстоятельств должны приниматься быстро.

Если все время придерживаться однажды принятой идеи и не вносить изменений в планы, в такой обстановке бизнес не сможет существовать долго.

Принцип 5. Доставлять быстро

Если вы смогли ликвидировать большую часть непроизводственных затрат, это влечет к сокращению сроков и стоимости на поставку готового продукта. Быстрая доставка невозможна без высокого качества.

Мне удавалось избегать ‘‘водопадной’’ методологии разработки вплоть до 1999 года, когда я приступила к работе над государственным проектом. Я была просто озадачена подобным подходом, потому что не могла понять, как это работает; и в действительности это не работало.

Принцип 6. Уважать людей

Быстрые поставки и высокое качество возможно только в коллективе, который работает как одна слаженная команда. Однако, по большей части создаются рабочие группы, а не команды. Отличие в том, что в группе работа каждого участника оценивается индивидуально.

Если участники разработки знают, что в конце проекта будет оцениваться лишь личная эффективность каждого, то логика подсказывает, что каждый сотрудник должны каким-то образом показать руководству, что он лучше остальных коллег. Например, поискать виновного в ошибке или показать чьи ошибки ему приходилось постоянно исправлять.

Вероятно, наиболее игнорируемым советом Деминга является следующий: ликвидировать ежегодные оценки индивидуальной эффективности для работников, которые на окладе; не следует подрывать сотрудничество в коллективе, награждая за индивидуальную эффективность.

Авторы считают, что участники команды должны вознаграждаться на основе достижений команды в целом, а не от вклада личных достижений. Например, тестировщики не должны награждаться за число найденных дефектов, а разработчики за количество написанных строк кода. Разработчики и тестировщики должны награждаться вместе, за способность создавать свободные от дефектов код. Весь коллектив должен быть вознагражден за экономический успех результатов их работы.

Принцип 7. Оптимизировать целое

Бесполезно оптимизировать какую-то одну часть производства. Необходимо расписать процесс создания продукта с момента заказа, до момента получения оплаты и оптимизировать поток создания ценности целиком.

Если в потоке создания ценности обнаружатся большие задержки между подразделениями организации. Любая идея, позволяющая ускорить поток создания ценности через эти барьеры, приведет к сокращению непроизводственных затрат.

Предпочтение индивидуальным поощрениям перед коллективными, плохие условия труда, неприемлемые сроки, отсутствие времени для должных тестирования и рефакторинга, навязанные процессы, рутинная (больше подходящая для роботов) работа и т.п.

Старайтесь искоренить все перечисленное: не создавайте конфликтных стимулов между членами коллектива, автоматизируйте рутинные задачи, предоставьте работникам самим определить оптимальные методы выполнения работы, никогда не требуйте соблюдения невозможных сроков. 

Это окажет куда больший положительный эффект, чем индивидуальные стимулы и премии.

Итоги

Семь принципов – лишь верхушка айсберга. В книге огромное количество интересных подходов и примеров. Правда, некоторые советы предполагают, что у вас неограниченный бюджет.

Кстати, в книге нет информации о подсчете стоимости производства. Прекрасно расписано, что нужно делать, но вот убеждать Клиента работать по такому подходу (когда большая часть рынка обещает фиксированные сроки на разработку) будет непросто.

Думаю, что в первую очередь книга пригодится руководителям IT-отделов, которые разрабатывают и поддерживают собственный продукт. Обычно в этом случае имеется стационарная команда или фиксированный пул подрядчиков. Также она будет полезна и веб-студиям.

Жалею, что не прочитал эту книгу раньше, она из разряда Must-have. К сожалению, последнее издание было выпущено в 2010 году и теперь её сложно найти в продаже.

Посмотреть книгу на Озоне

---

Тэги: книги, менеджмент
Постоянная ссылка