Рубрика «управление разработкой» - 101

Не писала на Хабр почти полтора года — обживалась на новой работе. Конечно же, в IT-сфере. Но общее весеннее обострение коснулось и нашей компании, появился повод написать. История такая: один из сотрудников написал хороший пост в свой личный блог на Хабр (NDA не был затронут). Чуть позже продакт менеджер сказал ему, что сделал он это зря и, если дойдёт до босса, будет грустно — потому что генеральный считает, что пост на Хабр = отправленное резюме на новую работу. Успешный пост с хорошим рейтингом убрали в черновики, дело замяли, мы тут спитые сплочённые. Коллега в печали — конечно же, он писал, чтобы поделиться своим опытом разработки и проектирования, а заодно померяться кармой.

Мой ник никто не знает, контору не спалят — вот и решила я написать утешения пост поговорить о той самой нематериальной мотивации. Не плюшками и креслами-грушами, а именно моментами, так скажем, шеринга знаний.

Чуть не уволили по статье… на Хабре - 1
Примерно так коллега видел свой диалог на ковре у боссаЧитать полностью »

Под катом вы найдете лонгрид на тему локализации игр, подготовленный на базе открытой лекции Алексея Медова — ведущего редактора Inlingo Game Localization Studio. Лекция проходила в рамках нашей образовательной программы «Менеджмент игровых интернет-проектов» в ВШБИ. О чем же мы поговорим в статье?
— о видах локализации и о том, как выбрать из них наиболее подходящий для вас;
— о том, как выбрать целевой рынок и в каких странах ваша игра будет наиболее востребованной;
— об особенностях разных стран и о том, что обязательно нужно знать перед тем, как начать локализацию своей игры;
— а также о том, как организовать сам процесс локализации.

Особенности локализации игр на иностранные рынки - 1

Читать полностью »

image

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

Переработки — прискорбная особенность нашей индустрии. Что с ней делать, пока кто-нибудь не решит её окончательно?

Обсуждая переработки, мы обычно спорим о том, бывают ли условия, при которых они приемлемы — «хорошие», а не «плохие» переработки — и что нужно изменить в индустрии в целом чтобы избавиться от «плохих». Я согласен, что было бы отлично, если бы индустрия начала меняться сверху: руководители могли бы взять на себя больше ответственности за улучшение условий работы и обеспечение более дружелюбной и устойчивой среды для разработчиков игр. Но такие изменения скорее всего будут медленными и постепенными. В мире огромное количество студий, и взгляды их руководителей на решение этой проблему резко противоположны. Их слишком много для единогласного принятия.

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

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

Как устроен поиск пакетных туров в стране, где люди не очень-то доверяют кредиткам - 1
Двухместный стандарт в Сочи в отеле Bridge Mountain стоит 86 рублей за сутки на человека на 1-6 апреля, и его можно взять отдельно от тура за 860 рублей на 5 ночей

5 лет назад мы обнаружили, что «Букинг» продаёт отели, всякие «Скайсканеры» и AWAD — авиабилеты, и голову поднимает AB&B. Но никто не продаёт туры целиком. Я тогда сказал своему другу: «Мужик, давай продавать туры. Это же очень просто сделать!»

А дальше начались такие круги ада, что мы несколько раз проклинали тот день. Началось всё с довольно простой задачи — синхронизации туров и их поиска. А прикол был в том, что если до нас у туроператора искали только руками из офисов, то с нашими поисками-сравнениями (на один запрос «Травелаты» поднимается около 500–600 туров в общем) мы просто клали их сервера к едрене фене. И туры не находились. Вообще, системы бронирования были сделаны в 90-х годах, а некоторые системы бронирования авиабилетов тащат легаси ещё чуть ли не со времён телеграфа.

Потом мы столкнулись с тем, что люди за пределами Москвы банально не доверяют кредиткам. Потом — с тем, что некоторые туроператоры очень любят, скажем так, недоговаривать цену при заказе. И так далее.Читать полностью »

В интернете кто–то неправ

Случайно выяснил, что существует непонимание того, что такое АБ–тест и как его проводить. Поэтому небольшая статья с базовыми принципами и примерами как делать не надо может быть полезна. Советы рассчитаны на читателя только начинающего знакомство с АБ–тестами и проект с небольшой аудиторией. Если у вас большая аудитория, то вы и так знаете как проводить тесты.
Мой опыт проведения АБ–тестов связан с мобильными приложениями, поэтому какая–то специфика может прорваться несмотря на намерения писать только о базовых вещах.

Определение

АБ–тест — это способ понять стал ли ваш продукт лучше при изменении его части. Скажем, у вас есть гипотеза, что какое–то изменение увеличит ключевую метрику продукта больше чем на 10%. Вы берёте новых пользователей и одной половине даёте контрольный вариант продукта, а другой — с реализованной гипотезой. Дожидаетесь пока разница между значениями метрики станет статистически достоверна, то есть не изменится при продолжении теста с вероятностью 90–95%. Как только результаты достоверны — оставляем победителя и запускаем следующий тест.

Читать полностью »

О чем? И для кого?

Случалось ли с вами, такое, что клиент увеличивает количество работ для вашей команды, хотя его требование, в принципе подходит под ТЗ?

Бывали ли ситуации, когда разработка затягивается, но не по вине вашей команды?

Не возникали ли у вас вопросы, как стоит действовать в ситуации, если разработка затягивается, хотя все идет как изначально планировали вместе с клиентом. И для клиента у вас нет объективной причины, кроме фразы “задача оказалась больше чем мы думали”.

В статье я стараюсь описать, что нужно сделать в первую очередь в той или иной ситуации и, что нужно обязательно не забыть.
Читать полностью »

Это вторая часть истории о маленькой стажировке в маленькой компании. В этой части рассказываю про то, как прошла стажировка 2013 года в действительности относительно разработанного ранее плана, здесь собраны наблюдения и результаты.

Первую часть можно прочитать по этой ссылке.
Читать полностью »

Помимо извечной проблемы отцов и детей, на мой взгляд, существует ещё одна проблема — подчиненных и руководителей. Именно об этой проблеме я и хотел бы поговорить в своей статье. Точнее, о таком частном случае, как взаимоотношения подчиненных и руководителей при разработке программного обеспечения, конструкторской и технологической документации. Руководители зачастую считают подчиненных безответственными разгильдяями, а подчиненные руководителей — некомпетентными пастухами, которым надо пасти стада, а не командовать подразделением разработчиков. Часто ситуация усугубляется непониманием, т.к. руководитель не разбирается в разработке, а подчиненный плохо понимает административные нюансы. Эта статья призвана помочь плохим руководителям стать хорошими руководителями. Вы, конечно, скажете: «Эй, полегче, какие ещё плохие руководители?». И будете, наверное, правы, я сильно сгущаю краски. Не очень-то и плохие. Обычные руководители, каких сотни и тысячи. Но чтобы качественно выстроить процесс разработки, нужны лучшие специалисты — и исполнители, и руководители. Поэтому руководителей я делю на хороших и не хороших. Без полутонов. Как и разработчиков, кстати, об этом сказано в последнем совете. Как понять, хороший Вы руководитель, или плохой? Почитайте нижеследующие правила. Если какие-то из них кажутся Вам чушью и потаканием бездельникам — значит статья написана для Вас.Читать полностью »

Преамбула

В последнее время встречаю много руководителей в IT, которые проповедуют, что ТЗ, таск-трекеры, аналитики, архитекторы и документация в разработке никчемные "вещи" и не стоит на них тратить время и средства. И ладно если бы люди делали внешние проекты, там это как-то я еще могу обосновать, но когда дело касается внутренней автоматизации бизнеса, тут я не могу с ними никак согласиться и говорю, что Вы просто не умеете их "готовить".

Читать полностью »

Я работала ведущим разработчиком в компании и, когда проект стал расширяться, стали брать еще людей и меня сделали руководителем группы. Так вышло, что я долго упиралась и хотела быть хорошим разработчиком, и чтобы от меня все отстали с руководством людьми. Через много лет, моему руководителю, все-таки, удалось меня научить как руководить, но этот путь был долгим и трудным. Я недавно прочитала статью "Delegation as Art" и вспомнила грабли, по которым прошла не один раз. Вот они во всей красе:

Это моя задача!. «Я ее хочу решить и никому не хочу отдавать. Как же я отдам эту задачу другому человеку, мне же так интересно придумывать и воплощать, а потом смотреть, как замечательно все работает.»

Грабли при делегировании, на которые я наступила - 1

Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js