Всем привет, с вами снова Роман Поборчий, и сегодня для разнообразия мы смотрим доклад не хардкорно-технический, а, скорее, менеджерский. Он был представлен на SQADays-20. Автор — Алексей i_vino Виноградов, и его выступление посвящено культу карго, синдрому not-invented-here и эффекту Даннинга-Крюгера.
Слайды тут:
На просторах интернета огромное количество информации по управлению проектами в IT-сфере и намного меньше информации о практике применения проектного подхода к разработке продуктов в машиностроении.
Данная статья будет интересна специалистам, которые занимаются управлением разработкой новых продуктов в сфере машиностроения и металлообработки. Инструмент, который я предлагаю использовать — это канбан на фундаменте приоритетов.
Сегодня я хочу поделиться двухлетним опытом проведения игры getKanban в Туту.ру. В целом, игровые механики мы используем довольно активно: играем в getKanban, Playing Lean, Lego Serious Game и т. д. Но getKanban, по нашему мнению, наиболее цельная и качественная игра. Для нас эта игра уже стала традицией и привычным инструментом обучения и коммуникации. Возможно, кто-то из читателей возьмет наш опыт на вооружение.
В силу своей профессии я выступаю и присутствую на конференциях, семинарах, заседаниях рабочих групп, лекциях и пр. Очень часто, практически всегда, заметно достаточно низкое качество представления презентаций, даже несмотря на безукоризненное понимание излагаемого материала самим докладчиком. Возможно, это связано с тем, что у нас нет уроков, лекций и курсов, включенных в стандартный образовательный процесс. Поэтому, каждый делает доклады кто во что горазд в меру своего понимания прекрасного. Тем не менее, какие-то базовые знания о создании доклада быть должны. И их можно обнаружить, например, в руководстве для $inline$LaTeX$inline$ пакета BEAMER, созданного как раз для подготовки презентаций. Но речь не о данном конкретном пакете и не о $inline$TeX$inline$-е, а о разделе 5 части I этого руководства, в котором содержатся общие рекомендации по подготовке докладов. И, поскольку, в большей своей части они полностью соответствуют моим представлениям, я решил сделать перевод для ознакомления широкой аудиторией, по возможности сохранив стилистику и форматирование.
Сразу пару замечаний:
1) пакет BEAMER оперирует другими, отличными от PowerPoint понятиями slide и frame (презентация состоит из серии фреймов, каждый фрейм, в свою очередь, состоит из нескольких слайдов), но на восприятии текста это не сказывается;
2) несколько раз в тексте встретятся команды TeX, но, в контексте они не потребуют объяснений.
Читать полностью »
Рассказы о личном опыте — самые ценные. Поэтому мы в Alconost с удовольствием перевели статью канадского инди-разработчика о локализации его первой игры на 7 языков. Слово автору.
Сразу оговорюсь: эта статья касается не только игр на Unity или инди-игр, но отдельные ее разделы сфокусированы именно на Unity, так что можете их пролистывать, если вам интересны общие советы по локализации. Я пишу это, чтобы помочь описать ВСЕ расходы, связанные с локализацией игры, и некоторые советы, как их сократить.
Первым делом давайте точно определим, что такое расходы. Я имею в виду не только потраченные доллары и центы, но все три вершины проектного треугольника (качество, время и стоимость). Локализация может сказаться на всех аспектах разработки вашей игры: ее общем качестве, количестве времени, которое понадобится для завершения проекта, и сумме, в которую вам обойдется локализация.
Читать полностью »
Хорошие навыки коммуникации нужны всем. Жизнь была бы намного проще и лучше, если бы все умели правильно общаться. Удалось бы избежать многих проблем и успеть сделать Великие Дела. Сегодня я расскажу про коммуникацию для дизайнеров, но подозреваю, что правила одинаковы для всех. Итак, вам пришло письмо или комментарий по работе…
Всё очень просто. Это похоже на волейбол. На чьей стороне мяч — тот проиграл. Вы получили письмо — мяч на вашей стороне, вы отправили ответ или макеты или вопросы — мяч на стороне “клиента”. В любой момент может прозвучать “свисток”. На чьей стороне мяч — тот проиграл. Старайтесь не держать мяч на своей стороне, передавайте его “противнику” при первой возможности.
12 простых правил:
1. Вас просят что-то сделать. Условия задачи понятны. Если вы не можете выполнить задачу за 1 час и сразу прислать решение или макет, то вы пишете письмо: “Привет! Я получил запрос. Решение будет в среду. Вопросов нет.” В среду присылаете дизайн.
Читать полностью »
Существует множество подходов к ведению IT- проектов и каждый из них находит своих последователей, успешно используется в одних проектах, с треском проваливается в других, приводит в восхищение часть клиентов и вызывает негодование у другой части. Порассуждаем о том, можно ли смешивать подходы, методы и методологии, чтобы достигать поставленных целей.
Важно!
Вот в таком виде нам его передали:
Задача — восстановить здание в legacy-виде и из legacy-материалов, а потом плотно набить инженеркой и поставить защищённый пункт связи.
Ответ на первый очевидный вопрос довольно прост: мы не только занимаемся железом и ПО, но и строим интеллектуальные здания. Обычно у нас, конечно, получаются дата-центры, тригенерационные центры, диспетчерские, центры чрезвычайных ситуаций и прочие вещи, где технологической начинки больше, чем бетона. Но иногда мы выигрываем в конкурсах на котельные и прочие объекты. Теперь вот досталось здание суда, благо строительный опыт есть.
На входе у нас был архитектурный проект, подразумевающий использование материалов, характерных для 37-го года. Мы делали всё — от земляных работ и усиления фундамента до инженерки.
Начать надо с того, что нынешнее здание суда во время ВOВ было штабом немецких захватчиков и одновременно офицерским борделем. В 90-х там открыли казино. Потом была гостиница. Под этими культурными слоями нам и нужно было найти сталинский ампир.Читать полностью »
Я продолжаю вызвавшие вас подозрительный интерес истории точек. Наша краснодарская команда — это просто отвал башки. Лёха приехал из Казахстана, по дороге чиновники потеряли ему отчество и банковскую карту. Вика из Белоруссии познакомилась с Лёхой, вышла замуж и переехала к нему в Воронеж. Ира из Мичуринска работала в Мосигре в Воронеже, откуда Женя её с треском уволил, а она решила доказать, что может открыть свою точку. Стас… Стас просто спокоен как удав, владеет вебстудией, коворкингом и любит путешествовать.
Началось с того, что все эти люди решили переехать за неделю в Ростов из Воронежа и открыть там магазин. Но попали в Краснодар. И открыли магазин там. Аренду первого помещения нашли раньше, чем выбрали, где жить — и квартиру сняли только у таксиста, который вёз их в гостиницу после осмотра будущей точки.
Хотя нет, началось всё раньше, когда вчетвером стали проводить вечера за настолками. Потом Ира устроилась в наш магазин работать, а спустя несколько месяцев была уволена за систематические опоздания. Расписание открытия и закрытия — это одна из тех вещей, за которую мы бьёмся до кости.
В тот же день, когда Ира осталась без работы, трое остальных друзей решили уволиться тоже и начать своё дело. Читать полностью »
Доброго времени суток! На написание статьи (да и самую регистрацию в ТМ) сподвигла статья «Ценообразование при создании сайта» — очень уж хочется сдвинуть некоторые точки над «i», дабы расставить их более «фен-шуйно». Ну естественно, с субъективной точки зрения. И вот эта самая точка зрения будет идти «изнутри» процесса и со стороны исполнителя, а не клиента. Но в целом — этот текст тоже для информации Клиенту, а не попытка безоглядной защиты «несправедливо обиженных» студий или отдельных дизайнеров. На «срыв покровов» и прочую сенсацию никто не претендует.
Ну, допустим. Но всегда нужно помнить о компетентности и уважении. Компетентности — потому что Клиент, как правило, ни в зуб ногой ни в трендах дизайна, ни в нюансах использования каких-либо cms или фреймворков. То есть, Клиент не знает КАК это работает и как должно. Уважение же должно присутствовать к самому процессу производства. Да, вы платите. Но заплатив за билет на самолет, вы же не лезете в кабину к пилотам со своими Ценными Указаниями? А если полезете — ну, тогда удачного полета.
Именно так происходит и в процессе разработки. Зачастую нет ни ТЗ, ни даже понимания зачем оно вообще надо. То есть, на этом этапе, Клиенту очень удобно говорить «ну вы же специалисты, вы итак знаете как надо». И если опыта у студии/дизайнера мало, то они сьедят это утверждение — что в последствии, в 90% случаев, приведет ко многим печалям для обеих сторон.
Читать полностью »
