Рубрика «планирование» - 15

Пишу игрушечную ОС (о планировщике)
Продолжаю вести блог о разработке игрушечной ОС.

В прошлом посте я писал о том, как добиться возможности реализовывать на C обработчики прерываний. Теперь, пользуясь написанными ранее макросами, можно реализовать простой SMP-планировщик. Он будет предоставлять минимально возможный функционал, на базе которого в будущем нужно будет возводить различные надстройки, в частности, примитивы синхронизации (например, мьютекс). Опять же, красивая модульная структура не способствует высокой производительности, но красота, как известно, спасёт мир, так что отдадим ей предпочтение.

Итак, попробуем сформулировать требования к нашему планировщику. Нам нужна возможность создать поток, указать для него стек, маску разрешённых логических процессоров (affinity), базовый приоритет и функцию выполнения. Далее, поток можно запустить, приостановить, продолжить его выполнение и, наконец, завершить.

Кроме того, было бы здорово, если бы планировщик не занимался выделением памяти, а мог принимать и возвращать память, выделенную под поток кем-то другим. С одной стороны, это бы обеспечило гибкость произвольного кеширования памяти потоков. С другой – дало бы уникальную возможность сохранять поток во внешней памяти (например, на жёстком диске) с последующей его загрузкой и запуском с прерванного места.
Читать полностью »

Как известно, самый ценный опыт – тот, что дается в «минус» себе: финансовый, эмоциональный, социальный… То, что «болит» и то, что нельзя просто так взять и забыть, как очередной неприятный сон.

Более года назад, для нас – команды RZLTT Accelerator, история проекта PromiseUP стала первой попыткой получить полноценный опыт создания, извините за избитое слово, стартапов, то есть самостоятельного бизнеса, от стадии идеи, на базе некоторого интернет-сервиса или продукта с отсутствующей логистической цепью или недвижимой инфраструктурой и самым простым, на сегодняшний день, способом распространения – бесплатной установкой на популярные у аудитории платформы, в первую очередь мобильные.

Пресловутый «экспириенс»

В принципе, начиная с третьего абзаца принято рассказывать о том, какие мы крутые, ми-ми-ми, посмотрите на наши фотографии, а вот наша симпатичная сотрудница, ну а продукт… да черт с ним, с продуктом!

В целом – это будет не success story, а откровенный рассказ о том, как все было на самом деле. Он полезен в первую очередь тем, кто грезит запуском собственного проекта и последующей стрижкой сотен миллионов с ничего не подозревающей, глупой, и ни о чем не догадывающейся аудитории.
Читать полностью »

Яблочко для тизера

Примерно три месяца назад мне, как руководителю студии дизайна, посчастливилось участвовать в замечательном тренинге «Основы бережливого производства». Тренинг этот рассказывал про методологию lean. Для тех, кто не в курсе — это методология “обезжиривания” бизнес-процессов, при которой идет сокращение неизбежных потерь, исключение бесполезных действий и выполнение других манипуляций, направленных на увеличение скорости работы компании, количества производимой продукции или услуг и, как следствие, роста её доходов. Это если вкратце.

То, чем сегодня я с вами хочу поделиться — это результат воплощения в жизнь лишь малой части полученных на этом тренинге знаний. Если вам будет интересна данная тема — я готов рассказать о других вещах, которые мы стали использовать в нашей студии после данного обучения. К слову, очень интересно читать посты на тему lean наших сибирских коллег — компанию Сибирикс. Ребята, так держать!

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

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

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

Собственная конституция как фундамент для постановки целей

И я стал учиться работать управленцем.Читать полностью »

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

    Литературы п управлению проектами написано много, но правильного ответа для того, самого животрепещущего, вопроса там нет. И скорее всего не будет. Я попытаюсь посвятить этот пост тому, чтобы максимально занудно описать причины печального положения людей, ищущих опоры и поддержки в своих попытках ответить на один из главнейших вопросов разработки ПО: сколько времени это займет?

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

Не так давно Стивен Синофски (экс-вице-президент подразделения Windows в Microsoft) начал вести свой блог, в котором он делится мыслями о продуктах, продуктовой разработке и управлении.
Мы с любезного разрешения автора решили заняться переводом его статей. Представляем вашему вниманию перевод первой статьи из этой серии.

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

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

Естественное напряжение (sic!)

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

Но кому нужно это «организованное напряжение»? Даже когда вы просто делаете, то что должно, вам и без того хватает стресса — зачем добавлять новый, от которого к тому же никак нельзя будет избавиться?

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

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

image

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

Посмотрим как они выкрутятся?
Читать полностью »

Инструмент планирования и контроля из подручных материалов

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

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

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

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

Велосипед

image
Итак, Вася долго трудился рядовым программистом, ведущим программистом и наконец стал Руководителем. У него есть команда отчаянных головорезов разработчиков в количестве двух единиц. Безусловно талантливых и знающих свое дело специалистов.

Вася получает первый заказ — надо сделать … велосипед. Читать полностью »

Мои правила управления бизнесом За 5 лет управления бизнесом, читая различную бизнес литературу, адаптируя и применяя ее на практике, я пришел для себя к следующим правилам успешного ведения бизнеса.

Эти правила не мотивация тех, кто еще только планирует заниматься бизнесом, по этой части написано немало книг, но если честно, я их не понимаю, мне кажется или человек имеет к этому тягу и тогда ему не нужны никакие мотивации, или нет, и тогда ему никакие мотиваторы не помогут. Это правила для тех, кто уже начал заниматься бизнесом, стал получать первую, пусть небольшую, прибыль и столкнулся с первыми трудностями. Почему важно начать получать прибыль? Потому, что мне кажется что у компаний который существуют за чей-то счет ( родственники, кредиты, гранты, госзаказы) немного извращенное понимание бизнеса и мои советы покажутся им скучными и неинтересными, ведь по их логике гораздо полезнее узнать, как получить гранд в Сколково или госзаказ на несколько миллионов. А начав получать эти гранты они уже не могут остановиться и вести бизнес нормально. Иногда заходишь в какой-нибудь айти-стартап, видишь в новостях, что он получил 3-5 грантов в течение одного года и понимаешь, чем они на самом деле занимаются. Но не будем о грустном. :)

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

Итак, вот мои правила:
Читать полностью »


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