Попросили меня на фирме выступить с докладом и рассказать о методологии по которой мы работаем, разрабатываем наше приложение. Я сразу же сказал — «У нас Scrum», и сел составлять презентацию. Но я остановился на первом же слайде, и вот почему.

Agile содержит в себе множество методологий — XP, Scrum, Lean, Kanban, ScrumBut (СкрамНО). Сев разбирать методики, я понял, что не могу сказать, что моя команда работает по какой-то одной из них. В целом наш рабочий процесс можно изобразить так:

За 6 месяцев из PDF—презентации получился продукт. С привлечением посевных инвестиций, драйвом командной работы, путешествием в Нью-Йорк, изучением английского права, сложностями, открытиями, разочарованиями и вдохновениями. Вот так создавался Manifest.

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

Вопросов, жалоб и предложений всегда много, поэтому и каналов саппорта у TeamLab сразу несколько и среди них как интерактивные: форма user voice, обращения по email, страница user feedback, онлайн-чат, аккаунты TeamLab в соц.сетях, так и справочные: Help Center, FAQ и блог.

Настоящий IT-шник всегда любит сварить «кашу из топора». А если этой кашей еще и получается вкусно накормить коллег, то выходит вообще замечательно.

По долгу службы мне постоянно приходится сталкиваться с различными инсталляциями bug и issue-трекеров (далее просто баг-трекеров) и среди них попадалось довольно много нестандартных решений. Что-то мне приходилось разворачивать самому, что-то я «подсмотрел» у клиентов, но поделиться наблюдениями было бы полезно.



С этой темой я уже выступал на конференции SQADays, но для тех, кому лениво смотреть 18 минут видео, все будет кратко расписано в статье.

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

В идеальном мире мы можем всё. В повседневности эта суперсила тускнет, но никуда не исчезает.
Смотрите, как просто разжечь огонь!

Запасаемся попкорном.

На недавно прошедшей конференции Application Developer Days 2012 мне довелось прочитать коротенький доклад о том, как создаются Open Source проекты на примере OpenVZ Web Panel. К сожалению, у меня было 10 минут, вместо положенных 30-40 и в результате 80% подготовленного материала оказалось “за бортом”. Организаторы, почему-то в последний момент передумали и убрали даже 5-минутную секцию с вопросами, так что остался без фидбэка. Но не буду сильно наезжать на организаторов — они старались как могли и конференция явно удалась, за что им огромное спасибо. Также очень порадовало и качество большинства докладов.


Теперь к сути топика — хочу выложить полную версию рассказа о том, как создаются Open Source проекты на примере собственного начинания, поделится мыслями и взглядами на разработку подобных проектов, рассказать о внутренней кухне, попробовать предостеречь от типичных ошибок.

Сегодня я хотел бы поделиться с уважаемыми читателями Хаброхабра своим опытом антикризисного управления, который произошёл совсем недавно (в самом начале 2012 года, если быть точным). Надеюсь, что описание этого опыта будет полезным всем прочитавшим, и каждый найдёт в нём что-либо полезное для себя. Ну и обсуждение в комментариях тех или иных аспектов, невыраженных умолчаний и прочего подобного всегда приветствуется — я постараюсь рассказать всё, что знаю.

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

С одним из таких опытов я как раз и хочу познакомить своих читателей. Речь пойдёт о простейшем проекте тестирования третьей стороной внедряемого в одном из крупнейших международных банков модуле взимания платежей.

Нашей компании уже 6 лет. Она была основана на принципах agile и росла на них. Мы использовали Extreme Programming с самого первого дня, добавили немного Scrum позже и в конце концов переключились на Kanban. Хочется поделиться бесценным опытом и рассказать об изменениях нашего процесса разработки за последние 4 года.