Переведено в Alconost Translations.
Если сегодня спросить у начинающих предпринимателей на кого они равняются, прозвучат привычные имена: Стив Джобс, Элон Маск, Марк Цукерберг, некоторые вспомнят еще Билла Гейтса. Но, к сожалению, немногие назовут Джеффа Безоса — основателя и генерального директора Amazon.
В моём личном опыте работы над проектами и развитием методологии проектного управления в организациях были различные эпизоды, которые могут стать отличными примерами как начинающим руководителям проектов с точки зрения поучительности, так и темами для обсуждения со зрелыми коллегами, умудрёнными в деле управления проектами. В связи с этим я начинаю серию публикаций о некоторых своих проектах, в которых выступал в разных ролях, но всё больше в качестве руководителя проекта. Сегодня я представлю почтеннейшим читателям первую часть героического эпоса о том, как в одной маленькой, но очень перспективной компании я занимался (среди всего прочего) построением и внедрением MIS — Management Information System. Этот эпос будет состоять из трёх занимательных частей для праздного чтения, после которых последуют комментарии с выводами о том, с какими проблемами я столкнулся, какие методы их решения существуют, каких ошибок следует избегать руководителям проектов.
Я знаю, что этот эпос обязательно прочитают сотрудники той компании, где всё это происходило. Я постарался написать нижеследующий текст как можно более анонимизирующе, и, более того, в тексте есть немного художественной приукрашенности, последовательность некоторых событий изменена, однако для знающих людей все аллюзии будут прозрачны. Надеюсь, что прочтение этого текста поможет моим бывшим коллегам понять мою точку зрения на происходившие в компании процессы и события.
Компания 37 signals — один из пионеров рынка SaaS и создатель фреймворка Ruby on Rails, знаменита не только своими софтверными продуктами, но и книгами Джейсона Фрида и Дэвида Хейнемейера Ханссона — Getting Real и Rework — которые основаны на реальном опыте разработки популярного софта и построения успешной компании. Обе книги стали бестселлерами. Осенью этого года выходит третья книга 37 signals под названием REMOTE: Office Not Required. Она посвящена преимуществам и организации удалённой работы.
Большинство своих предыдущих статей я писал со стороны ИТ специалистов и компаний (Как отпугнуть высококлассных специалистов. Руководство для компаний, Разбор полетов: как нужно описывать вакансии, Когда я говорил...), сегодня же хочу взглянуть на процесс выбора исполнителя глазами заказчика.
Вам приходилось делать ремонт, например, заказывать двери в квартиру? Казалось бы, ничего сложного: зашел в поисковик, ознакомился с ассортиментом, выбрал подходящую модель, осталось дело за малым — выбрать компанию-исполнителя, у которой соотношение цена / качество / время будет оптимальным.
Несколько движений по клавиатуре — и вот перед вами уже список потенциальных компаний. В процессе сбора и анализа информации об этих компаниях вдруг оказывается, что цена на двери у всех одинаковая, так как они получают продукцию от одного и того же производителя (при этом цена на сайте производителя такая же). Здесь вы впервые ощущаете дискомфорт, так как не можете понять, на чем же зарабатывают компании и какие у них конкурентные преимущества.Читать полностью »
Добрый день читатели! Не так давно я начал искать работу на позицию junior разработчика. Даже благодаря моему скромному резюме мне удалось побывать на не малом количестве собеседований за сравнительно малый промежуток времени. Из каждого собеседовании я выносил для себя что то новое, где то были мои проколы, но гораздо интереснее было замечать фэйлы меня собеседующих. Собственно о таких проколах я и хотел бы рассказать.
Читать полностью »
«— Запомните главное: ВЗК — Всегда Заключайте Контракты. Идите к людям, человек не приходит, чтобы отдать вам свои деньги сам» − фильм «Американцы»
Цитата из фильма «Американцы» напрямую связана с ошибкой, которую мы допустили, начиная свою деятельность. Наша компания Touch Instinct занимается разработкой мобильных приложений. Вспоминать сложившуюся ситуацию можно немного иронически и даже с юмором, но в тот момент было не до шуток.Читать полностью »
Очередной этап Формулы-1. Напряженная гонка на запредельных скоростях. Пит-стоп, замена резины. Слаженная команда механиков за считанные секунды меняет колеса и болид продолжает гонку. Один профессионал — одна задача. А теперь представьте, что все колеса меняет один механик, или у каждого колеса мнется в растерянности целая команда, все мешают друг другу и дают бесконечные советы. Гонка безвозвратно проиграна.
Итак, представим, что гонкой в нашем случае является коллективное редактирование одного объекта — документа (простого или многостраничного, с рисунками, таблицами и прочими атрибутами). Как правило, предметом совместного редактирования являются объемные документы, требующие внимания всех подразделений организации: годовые отчеты, бизнес-планы, проекты бюджета, положения и соглашения, стратегии развития и управления рисками, методики и т.д. Выбор надежного и профессионального инструмента совместного редактирования — важный момент при работе с корпоративной документацией.
Локализованная игра. Слов тут нет.
Экономика — очень прикольная штука, которая часто заставляет делать странные вещи. Например, есть игра «7 на 9», в которой нет ни одного английского слова, только цифры. И всё же мы занялись её локализацией для того, чтобы иметь возможность продавать почти в два раза дешевле.
Вообще, в каждой сфере начиная от продажи железа и заканчивая косметикой, есть огромное количество мифов про цену настоящую товара. Например, многим вспоминается фраза, что себестоимость кроссовок Адидас — 2 бакса, а остальное они добавляют за логотип. Ещё некоторые не верят, что обычные налоги в нашей стране составляют больше 50%, потому что привыкли к «разрекламированным» 13%.
Вот про эти мифы я и поговорю на примере точного образования цены настольной игры. Читать полностью »
Любому приличному программисту известно, что грамотно написанная система должна иметь хорошую архитектуру, обеспечивающую чёткую структуру, удачное сочетание и взаимодействие объектов, чётко распределённые между объектами роли и разделение на слои.
Каждый приличный руководитель проекта знает, что для успешного, сданного в срок проекта хорошего качества (который, к тому же, не слишком вылез из бюджета) необходим отлаженный процесс, обеспечивающий прозрачное взаимодействие между членами команды, чёткое распределение ролей и обязанностей, полномочий и ответственности. Т.е. грамотная архитектура команды.
В этой статье я (очевидно, не слишком серьёзно) попробую спроецировать основные принципы ООП на проектное управление и посмотреть, что из этого получится.
До последнего времени мне обычно приходилось разрабатывать приложения на собственный вкус. Связано это было с тем, что в 1С: Предприятии не слишком большой выбор дизайнерских решений. Правда, широкий простор в решении, что будет на форме, чего не будет, в какой последовательности разместить элементы и как их скомпоновать никто не ограничивал.
И вот я стал стартапером. Начали разрабатывать приложение под iOS, приложение на Flex, и еще специализированную социальную сеть. И тут-то выяснилось, что вкус мой довольно кислотный, люблю «вырви глаз», а клиенты этого не любят. Пришлось искать дизайнера.Читать полностью »
