Встречаясь с огрехами и ошибками удобства очередной CRM/системы управления проектами — возникает мысль написать-таки свой велосипед, однако экономическая ситуация в нашей стране, да и отсутствие многих часов времени на контроль останавливает меня от столь разумного шага, поэтому — приходится выбирать из того, что есть.
А раз уж все равно выбирать — почему бы не написать об этом? (далее…)
Трудоголиков становится все больше, а предприниматели, программисты, дизайнеры и маркетологи часто объясняют свои переработки тем, что им просто нравится своя работа.
По результатам исследования, проведенного в Стэнфордском университете, программисты, которые проводят в офисе на 20 часов в неделю больше нормы (то есть 60 часов вместо стандартных 40), выполняют свою работу менее качественно. Таким работникам чаще нужен отдых, чтобы их производительность не страдала.
Мы в 1cloud рассматриваем самые разные темы, связанные с ИТ. Сегодня мы решили немного поговорить о культуре работы и отдыха, рассмотрели примеры отпускных поощрений некоторых ИТ-компаний и общую ситуацию с модой на трудоголизм.
Мы продолжаем расспрашивать специалистов о режиме труда и отдыха, профессиональных привычках, об инструментарии, который они используют, и многом другом.
Будет интересно выяснить, что их объединяет, в чем они противоречат другу другу. Возможно, их ответы помогут выявить какие-то общие закономерности, полезные советы, которые помогут многим из нас.
Сегодня наш гость — Петр Зайцев, генеральный директор, основатель Percona. Он считает себя не самым организованным руководителем. Более того, Петр, будучи человеком технического скалада, называет себя «нетипичным СЕО». (далее…)
Хотите ускорить рост, повысить конкурентоспособность, вырваться вперед? Тогда, возможно, пришло время переосмыслить свой подход к планированию продукта. Дженна Бэстоу из Invision делится в блоге компании опытом внедрения тематических дорожных карт в рабочий процесс и рассказывает о преимуществах, которые принесло команде это решение.
Тематические дорожные карты проекта — это не пошаговая методика; они не предполагают строгих правил и не привязывают вас к определенному продукту или программе. По сути, это просто гибкий подход к разработке стратегии.
Выглядит он так:
А звучит так:
«Что готовит будущее, мы не знаем. Поэтому вот список того, что мы хотим сделать, в общих чертах, а коррективы вносить будем по ходу дела».
(далее…)
Вторая статья про мифологическое сознание тоже будет короткой. Сегодня я расскажу, к каким проблемам приводит мифологическое сознание при моделировании архитектуры предприятия.
Известная модель Захмана пытается ответить на вопрос, что такое архитектура предприятия, и рассказывает о том, как она должна моделироваться. Основой этой модели являются вопросы, на которые предлагается ответить: кто, когда, где, почему и как совершает что-то над чем-то. Кажется, что это логичный фреймворк для описания архитектуры предприятия, и многие думают, что так оно и есть.
Однако, даже беглый взгляд на этот фреймворк оставляет чувство неудовлетворенности, потому что не понятно, как ответить на вопрос: кто и почему выточил деталь? Кто: Иван Иванович, или токарь, роль которого исполнял Иван Иванович? Почему: потому что токарь получил задание, или потому что Иван Иванович заключил контракт, в соответствии с которым он обязуется выполнять роль токаря в обмен на еду? Почему: потому что Иван Иванович хочет покушать, или затем, что деталь нужна в сборочном цехе?
Более глубокое изучение этого фреймворка заставляет задуматься над его применимостью к описанию технологических процессов. Например, пусть кукуруза растет в поле. Применяя модель Захмана, я должен ответить на вопросы. Кто? Кукуруза. Что делает? Растет. Почему? Потому что так устроен мир. Зачем? Да кто же его знает, зачем растет кукуруза?!
Наука, связанная с обработкой данных, продолжает волновать людей, однако реальные результаты нередко вызывают разочарование у заинтересованных бизнесменов. Как мы можем снизить риски и обеспечить соответствие результатов ожиданиям? Работа в качестве технического специалиста на стыке НИОКР и коммерческих операций дала мне представление о проблемах, которые стоят на этом пути. Я представляю свою личную точку зрения на наиболее распространённые виды провалов и неудач проектов, связанных с информатикой.
(далее…)
Методика освоенного объема (МОО) 1 2– технология обкатанная и, однозначно, эффективная. Однако, решившись ее применять, следует иметь в виду несколько явных и известных ограничений, которые сильно снижают коэффициент ее полезности её КПД.
Во-первых, применять МОО следует только после того, как прошла некоторая часть проекта (порядка 15%-20% 3. Эта фора необходима для того, чтобы накопилась достаточная статистика по проделанной уже работе, и показателям, входящим в методику, таким как SPI/CPI, можно было бы смело доверять.
Во-вторых, именно базовые показатели МОО не учитывают связанность проектов между собой и влияние форс-мажорных событий на результаты отслеживаемого проекта и будущих задач. Например, если ключевой разработчик внезапно заболел или неожиданно уехал по срочным делам – срываются сроки текущего проекта, а также сдвигаются сроки последующих работ, которые запланированы на него, но пока не мониторятся. В силу того, что плановые задачи находятся в категории «будущего», их показатели не измеряются. Тем не менее, случившийся сбой на них в перспективе тоже отразится.
Именно поэтому, применяя МОО на практике, следует учитывать данные риски и снимать ограничения, которые были обозначены выше. Рассмотрим этот принцип на примере некоей ИТ-компании, занимающейся реализацией проектов в интересах заказчика.
Понятно, что в одной короткой статье нельзя уместить весь спектр рисков, с которым сталкиваются в повседневной деятельности руководители проектов и производственных подразделений. Тем не менее, этот пример позволит узнать, как заранее разглядеть «грабли» заботливо разложенные реальностью, и обойти их, не сломав при этом производственные процессы.
Евгений Невгень, основатель компании MSQRD, в рамках открытого интервью на Форуме Gotech поделился историей создания бизнеса, который он продал Facebook, и раскрыл секреты формирования команды проекта.
Все началось с увлечения программированием. В 19 лет первым успешным проектом стал благотворительный аукцион встреч MaeSens (в России он известен как GoodWillion). Мне всегда было интересно, как делать правильный работающий дизайн. И мы с партнером Максимом Каменковым основали компанию SplitMetrics – платформу A/B-тестирования страниц приложений в App Store и Google Play. Буквально через месяц после объявления об открытии компании, нашим клиентом стала Rovio.
Все свои проекты с партнерами мы запускаем на Хакатоне, где можно получить быструю обратную связь. Эта стратегия нас никогда не подводила. MSQRD также создавался на Хакатоне. Именно благодаря ему он и появился в таком виде. Тогда мы сделали первую самую упрощенную версию приложения, и людям это очень понравилось. Пришлось пообещать, что через две недели выпустим MSQRD в AppStore. И нам это удалось. (далее…)
Мы продолжаем расспрашивать специалистов о режиме труда и отдыха, профессиональных привычках, об инструментарии, который они используют, и многом другом.
Будет интересно выяснить, что их объединяет, в чем они противоречат другу другу. Возможно, их ответы помогут выявить какие-то общие закономерности, полезные советы, которые помогут многим из нас.
Сегодня наш гость — Илья Космодемьянский, генеральный директор PostgreSQL-Consulting LLC. У Ильи предельно простой лафхак на все случаи жизни. А одним из своих авторитетов он считает В. И. Ленина. (далее…)
После регистрации общество с ограниченной ответственностью ставят на налоговый учёт, и компания, вместе с правом вести бизнес, получает определённые обязанности. Не все эти обязанности очевидны и известны новичкам в бизнесе. Чтобы не было мучительно жалко в первые же месяцы платить штрафы из своего кармана, советуем учредителям ООО убедиться, что вы знаете, как избежать ненужных потерь.
(далее…)
