Волею судеб, запуская очередной проект, я столкнулся с достаточно интересным фактом.
Многие мои знакомые так или иначе пытаются делать проекты, получается у немногих.
Я хочу рассказать на небольших примерах о том, что нужно делать в проекте, а на что можно забить, даже если это противоречит вашим интуитивным устремлениями.
Читать полностью »
В продолжении темы, почему иногда нужно делать свой велосипед, хочу дополнить и расширить эти мысли причинами, по которым этого делать не стоит.
Посмотрите внимательно на предыдущий топик. Генри Форд — с детства изучал технику. Его сестра как-то сказала, что в детстве любую игрушку старались спрятать от него, потому что он ее тотчас разберет на винтики. Работал инженером в «Электрической компании Эдисона», был совладельцем «Детройтской автомобильной компании». Он точно знал, что такое — автомобиль. Он точно знал технические нюансы. Он точно знал. что черная краска сохнет два дня, а любая другая — две недели! Ну не из-за прихоти же он однажды сказал, что автомобиль будет только черным.
Игорь Сысоев, прежде чем делать свой nginx, уже имел «достаточно неплохой опыт работы с Apache — и как у системного администратора, и как у программиста».
Знаете ли вы, что вам предстоит на пути создания своего велосипеда? Или просто готовы окунуться с головой, не проверив глубину водоема?
Мы как-то по просьбе своего заказчика сделали реализацию почтовой рассылки, которая делала рассылку новостей зарегистрированным пользователям. И каково было удивление нашего заказчика, когда после первой такой рассылки его заблокировали как спаммера. Пришлось копать дальше, но в итоге оказалось, что гораздо проще интегрироваться с каким-нибудь MailChimp и не изобретать велосипеда. Там не только все продумано, но есть еще и отчеты — сколько прочитало, сколько кликало по ссылкам, сколько нажали «отписаться от рассылки» и другие очень важные моменты, которые заказчик, попросивший «сделайте нам возможность разослать новости нашим пользователям», может захотеть сделать сразу же после реализации базового функционала.
Самые крутые инструменты — универсальны, с их помощью можно решать самые разнообразные задачи. Примеры таких инструментов — документы и таблицы Google, ментальные карты Mindmeister, доски Realtimeboard. Вы можете их приспособить для чего угодно, особенно таблицы. Придумать и сделать такой инструмент сложнее всего. Я расскажу о еще одном универсальном инструменте, который мы активно используем — Tom's Planner.
Читать полностью »
«— Запомните главное: ВЗК — Всегда Заключайте Контракты. Идите к людям, человек не приходит, чтобы отдать вам свои деньги сам» − фильм «Американцы»
Цитата из фильма «Американцы» напрямую связана с ошибкой, которую мы допустили, начиная свою деятельность. Наша компания Touch Instinct занимается разработкой мобильных приложений. Вспоминать сложившуюся ситуацию можно немного иронически и даже с юмором, но в тот момент было не до шуток.Читать полностью »
Очередной этап Формулы-1. Напряженная гонка на запредельных скоростях. Пит-стоп, замена резины. Слаженная команда механиков за считанные секунды меняет колеса и болид продолжает гонку. Один профессионал — одна задача. А теперь представьте, что все колеса меняет один механик, или у каждого колеса мнется в растерянности целая команда, все мешают друг другу и дают бесконечные советы. Гонка безвозвратно проиграна.
Итак, представим, что гонкой в нашем случае является коллективное редактирование одного объекта — документа (простого или многостраничного, с рисунками, таблицами и прочими атрибутами). Как правило, предметом совместного редактирования являются объемные документы, требующие внимания всех подразделений организации: годовые отчеты, бизнес-планы, проекты бюджета, положения и соглашения, стратегии развития и управления рисками, методики и т.д. Выбор надежного и профессионального инструмента совместного редактирования — важный момент при работе с корпоративной документацией.
Любому приличному программисту известно, что грамотно написанная система должна иметь хорошую архитектуру, обеспечивающую чёткую структуру, удачное сочетание и взаимодействие объектов, чётко распределённые между объектами роли и разделение на слои.
Каждый приличный руководитель проекта знает, что для успешного, сданного в срок проекта хорошего качества (который, к тому же, не слишком вылез из бюджета) необходим отлаженный процесс, обеспечивающий прозрачное взаимодействие между членами команды, чёткое распределение ролей и обязанностей, полномочий и ответственности. Т.е. грамотная архитектура команды.
В этой статье я (очевидно, не слишком серьёзно) попробую спроецировать основные принципы ООП на проектное управление и посмотреть, что из этого получится.
Менеджмент, как техпроцесс, является основным и неотъемлемым фактором развития проектов. В подавляющем большинстве случаев для стартапов нанять опытного менеджера представляется сложным — услуги достойного специалиста стоят недешево, да и доверять на раннем этапе постороннему лицу участникам стартапа будет сложно.
Поэтому менеджментом занимаются, как правило, сами участники проекта.
И это не является оправданием профанации. Для достижения успеха, все основные детали проекта должны быть проработаны. И менеджмент ИТ-проекта не является менее значимым, чем маркетинг, реклама, PR, программирование или дизайн. Скорее наоборот — от качества управления проектом в первую очередь зависит его судьба.
На хабре есть много тем по специфичным аспектам менеджмента проектов. Но именно основы менеджмента до сих пор не были освещены.
Попробуем закрыть этот пробел.
Кратко обозначены, выделены и пояснены основные, наиболее важные моменты.
Читать полностью »
Всем привет, нас зовут Leto, мы — английская компания, основанная двумя русскоязычными парнями. Мы создаем стартапы для наших клиентов. Иногда они обычные люди, которые решили начать свой бизнес и запустить стартап (например Sorted), а иногда это большие и состоявшиеся компании (например 20th Century Fox), которые пытаются запустить новый продукт или услугу. Мы помогаем им улучшить концепт, проработать бизнес-модель, мы разрабатываем сам продукт и создаем дизайн, запускаем, раскручиваем, анализируем — вобщем, мы стараемся делать все (или все из того, что требуется). Если вам знаком термин “lean startup”, то наш бизнес — это “lean startup as a service”.
Как и любой компании-разработчику, нам нужен был инструмент для управления проектами (или попросту “трекер”). Как и полагается, мы перепробовали много разных сервисов, но все как-то не подходило, и в результате мы создали свой очередной трекер простой и удобный сервис, который использовали внутри компании и давали своим клиентам. Почему, зачем и что из этого вышло — читайте под катом.
В этой статье я хочу поделиться своим опытом более чем десятилетнего управления и участия в различных ИТ-проектах в государственном секторе. Речь пойдет об управленческих особенностях работы с государственными структурами, вы увидите, чем исполнение Государственного контракта отличается от коммерческого договора.
Специалисты по управлению проектами относят проекты, связанные с разработкой и внедрением информационных систем, к категории наиболее сложных. Более того, в силу специфики работы с государственными структурами управление проектами не может достигнуть достаточного уровня эффективности при использовании стандартных подходов.
Основная часть проектов в государственном секторе происходит по схеме, когда руководитель проекта (исполнитель Государственного контракта) несет полную ответственность за проект в пределах фиксированной цены и оговоренных штрафных санкций (вплоть до внесения в реестр недобросовестных исполнителей). Заказчик (госструктура) при этом не несет никаких рисков.
Читать полностью »
Наша команда перепробовала множество инструментов для управления проектами. Практически все они имели серьезный недостаток – были слишком сложными и громоздкими. В итоге даже простая операция создания задачи и назначение исполнителя вызывала раздражение и всякое нежелание пользоваться инструментом в дальнейшем. Согласитесь, что главная задача любого инструмента – облегчить жизнь, а не усложнить ее.
Около полугода назад я познакомился с сервисом Asana. Сначала начал использовать в личных целях, но в конце концов пришел к тому, что лучше использовать единый инструмент в том числе и на работе.
В качестве хранилища исходного кода мы используем облачный TFS, соответственно, управление проектами осуществляем там же. Но для нас он оказался слишком громоздок. Да и клиенты, когда видели то, с чем им придется сталкиваться каждый день, предлагали использовать Google Docs или Excel и не усложнять им жизнь.
Читать полностью »
