Работодателю о служебном изобретении
Изобретения делают люди. Деньги на изобретениях делают фирмы. Как фирме избежать проблем с автором изобретения и другими заинтересованными лицами? Читайте разъяснения патентного эксперта.
(далее…)
23
Окт
2013
Окт
2013
23
Окт
2013
Окт
2013
Планирование сроков и бюджетов для фрилансера
Вот уже почти три месяца я уволился из офиса и работаю на «вольных хлебах». «Халтуры» попадались и до этого, но я не брал более одного проекта и делал лишь то, что входило в мою широкую, но не безграничную область компетенции.
Я занимаюсь «программированием под ключ» и считаю себя μISV. Специализируюсь на проектах, требующих смежной компетенции, обычно я работаю с заказчиками долго — по нескольку лет. Я за то, чтобы исполнитель и заказчик работали вместе и помогали друг-другу найти оптимальное видение проекта. Мой процесс разработки выглядит так: (далее…)
23
Окт
2013
Окт
2013
Решение проблем: 10 правил менеджера
Рассмотрим следующую ситуацию: вы — проджект-менеджер, и на вашем проекте возникла проблема. О том, как поэтапно добраться до источника проблемы и ликвидировать ее, я подробно расскажу в сегодняшней статье.
У меня все работает!
Существует расхожее мнение, что проблемы решают исполнители, а управленцы только ходят и мешают. Однако что происходит, если на проекте нет менеджера? Представим ситуацию: в саппорт приходит гневное письмо: «Я нажал на кнопку, а там 500-я ошибка!». Причем письмо приходит не одно, то есть проблема массовая.
(далее…)
23
Окт
2013
Окт
2013
О методе освоенного объема в разработке ПО. Изучаем PMBOK
Главная задача менеджера удержать проект в пределах «железного» треугольника. Поэтому ему просто необходимо анализировать и прогнозировать отклонения проекта по срокам и затратам. PMBOK (A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Fifth Edition, Project Management Institute, Inc., 2013) рекомендует использовать для такого анализа метод освоенного объема (Earned Value Technique).
Бытует мнение, что этот метод не применим в управлении программными проектами. Это действительно так, если мы используем «водопадную» модель процесса разработки, в которой на верхнем уровне декомпозиции находятся производственные процессы: анализ, проектирование, кодирование, тестирование, документирование. Даже закодировав 90% требований, мы, к сожалению, ничего не можем сказать о готовности нашего продукта. Может оказаться так, что при проектировании была допущена ошибка и большую часть кода придется переписывать.
Однако, если иерархическая структура работ нашего проекта, ориентирована на итеративную и инкрементальную разработку, то на верхнем уровне декомпозиции находятся компоненты проектного продукта, а на следующем — их функционал. В ‘том случае метод освоенного объема вполне себе применим. Поскольку, если в проекте реализованы, протестированы и документированы 50 % функциональных требований (а лучше, если еще и представлены заказчику), то есть все основания полагать, что осталась приблизительно половина проектных работ.
Суть метода оценки проекта по освоенному объему заключается в следующем.
(далее…)
23
Окт
2013
Окт
2013
Принципы успешной техподдержки
Этот текст был задуман как попытка структурировать основные принципы успешной технической поддержки и общения в целом. Под «успешной» в данном контексте подразумевается положительная реакция непосредственно клиента на качество сервиса, т.е. его конкретное субъективное мнение по итогам обращения в техподдержку.
Немного об авторе: никакого психологического образования не получал, курсов общения с клиентами не проходил, так что все выводы основываются исключительно на личном опыте. Я начал работать в технической поддержке более 8 лет назад, в компании Acronis, тогда еще совсем небольшой, а штат техподдержки не превышал 10-15 человек. Сегодня в техподдержке участвует более 250 человек, поддерживая клиентов на девяти языках мира. Со временем я прошел все этапы — от работы в небольшом коллективе с практически нулевым уровнем личной ответственности до контроля и взаимодействия в большой инфраструктуре, включающей автоматический сбор статистики по каждому сотруднику для замеров его личного KPI (key performance indicators).
Благодаря длительному общению с пользователями (как правило, англоговорящими) сами собой выкристаллизовались манеры успешного общения — что именно нужно делать и как себя вести, чтобы клиент остался доволен. Эти правила одинаково применимы не только к технической поддержке программных продуктов, но и к общению с клиентами в любой другой отрасли, так что, надеюсь, сей опус будет полезен не только узким специалистам, но и пригодится в повседневном общении. Лично мне это сильно помогло.
22
Окт
2013
Окт
2013
Учет отработанных часов: за и против
Привет, Хабр!
Когда в разговорах с айтишниками заходит речь про учет трудо-часов, холивор зажигается моментально. И не важно, с кем про это говорить: тема задевает и рядовых разработчиков, и тимлидов, и топ-менеджеров. Предлагаем на обсуждение наше видение темы с учетом часов — может, мы продвинемся немного в поисках истины в процессе обсуждения.
22
Окт
2013
Окт
2013
Цикл зрелости технологии (Hype cycle) Gartner — при внедрении новой системы на предприятии
-Gartner-—-pri-vnedrenii-novoi-sistemy-na-predpriyatii.png "Цикл зрелости технологии (Hype cycle) Gartner — при внедрении новой системы на предприятии")
В 1995 году исследовательская компания Gartner предложила hype cycle — кривую зрелости технологии, графически представляющую стадии, через которые проходит технологическое новшество в ходе своего становления.
Данный феномен наблюдается при появлении любой новой техники, будь то появление планшетов на рынке или внедрение новой CRM системы на предприятии.
Про то как эта кривая работает в части электроники, написано много статей.
А вот как она работает в ходе внедрение новой системы в организации?
(далее…)
22
Окт
2013
Окт
2013
6 заблуждений в методологии «Бережливый стартап» («Lean Startup»)
.png "6 заблуждений в методологии «Бережливый стартап» («Lean Startup»)")
Привет, хабражители! Каждый день в мире появляется и исчезает огромное количество стартапов. В разных странах, в разных сферах. Многие предприниматели мечтают найти формулу успеха в какой-то книге по личностному росту или на конференциях и других мероприятиях. Большого внимания заслуживает книга Эрика Райса — «Lean startup», положившая начало популярному движению в стартаперской культуре. Модель «Бережливый стартап», набирающая популярность в России и СНГ, помогает строить стартапы малыми ресурсами, за счёт уменьшения циклов разработки. Все в этой модели вроде бы очень хорошо и «must read» предпринимателям, но некоторые нюансы описаны ниже и будут очень полезны для ваших будущих и текущих проектов.
(далее…)
22
Окт
2013
Окт
2013
Как я был идеальным заказчиком
Это поучительный рассказ о том, как после многих лет работы на стороне исполнителя мне довелось побывать по ту сторону баррикад и заказывать разработку на стороне. Это рассказ о том, почему для разработчика нет ничего страшнее идеального заказчика.
Как я уже говорил, я много лет занимался работой с заказчиками в софтверной компании. Так вот – мне приходилось работать с разными заказчиками – с отечественными и с зарубежными, с международными корпорациями и со стартаперами-одиночками.
Я видел всё, что только бывает. Я видел пафосных московских менеджеров, к которым надо было приезжать раз в неделю, потому что говорить по телефону – это западло, и видел простого американского парня, который взял и прилетел на месяц к нам в Сибирь под новый год, чтобы лично объяснить разработчикам, чего он хочет.
Я работал со странными людьми, которые составляли ТЗ в половину странички, с неадекватами, которые переписывали спецификацию раз в неделю, с мудаками, которые считали себя рабовладельцами. Мы делали фичи, которые не поддерживало железо, разрабатывали приложения под ось, которая еще не вышла и адаптировали под ретину дизайн, нарисованный ребенком в редакторе Paint. Я работал с психами, которые грозились миллионными штрафами за день просрочки промежуточного релиза.
Я имел дело с перекупщиками, которые понятия не имели, чего хочет конечный покупатель, я встречал неадекватов, которые понимали как надо только после того, как мы сделаем, как просят.
Я работал с заказчиками, которые «я вообще-то тоже программист» и пытались учить нас делать свою работу. Я знаю, что такое переделывать всё с нуля по три раза за проект.
Однажды у меня был заказчик, соскочивший с проекта, потому что у него сгорел офис со всем железом и данными. Однажды нам пришлось за 200 баксов делать клон, хотя нет – продвинутый клон родного яблочного приложения в то время, когда они еще не открыли сторонним разработчикам доступ ко многим своим фичам.
В общем, я работал со всеми видами невозможного и невыполнимого. Я понимаю, каково делать то, не знаю, что, так, чтобы еще вчера было готово.
Так вот — каждый раз, когда я встречал очередного «чего там работать, сделайте как в фейсбуке» клиента, я давал себе слово, даже нет – я клялся могилами предков, что вот уж я бы на его месте так себя не вел. Я бы на его месте работал так, что разработчик еще и приплачивал бы за удовольствие иметь со мной дело. Уж я бы на его месте мог бы стать просто самым лучшим заказчиком. И однажды я им стал.
22
Окт
2013
Окт
2013
Установка «Redmine» на «Linux Ubuntu» с прозрачной аутентификацией в домене (Apache, Passenger, RVM, MySQL)
Данным постом хотелось бы начать цикл статей о том, как мы адаптировали под свои нужды трекер задач «Redmine».
Около 2-х лет назад мне пришлось достаточно сильно изменить профиль своей деятельности, и от системного администрирования уйти в разработку на фреймворке «Ruby on Rails». Нужно было адаптировать «Redmine» под нужды достаточно большого IT-отдела, а потом и под нужды компании в целом. Тогда, я столкнулся, с относительной не простотой установки «Redmine». И комплексной статьи для новичков очень не хватало!
Есть несколько способов установки ROR-приложения, которым является «Redmine». В данной статье речь пойдет об установки на web-сервер «Apache», с использованием «Passenger» и «RVM». В качестве сервера баз данных, мы до сих пор используем «MySQL» (вернее MariaDB), хотя и подумываем о переезде на «PostgreSQL».
(далее…)