16 декабря 2009 г.
5 ноября 2009 г.
Внутренняя проблема – помеха проекта!
В компанию поступил запрос на разработку Системы для контроля внутренних процессов. Заказчик занимается неким производством товаров массового потребления.
Для производства конечной продукции Заказчиком используется некое оборудование и продукты. К основным затратам производства следует отнести затраты на продукты для конечной продукции, затраты на обслуживания техники и заработная плата рабочих.
Конечный производимый продукт имеет свойство возврата после его продажи поставщикам. Т.е. продав партию продукта поставщику, есть вероятность, что часть продукции снова вернется в компанию. Продукт, который вернули, снова попадает в цепь производства.
Как и в любой компании, в процессе производства участвуют несколько отделов и множество рабочих. И как часто бывает - проконтролировать все производство практически невозможно. Благодаря «нашему брату» часть начальной и даже конечной продукции пропадает без следа.
Кому, прежде всего, нужна Система, которая бы дала общую картину производства «на экране»? Ответ очевиден – владельцу компании.
Основной инициатор идеи завестись Системой – это директор. Второе лицо, которое принимает решения «интеграции» или даже запуска Системы – это коммерческий директор.
Первая встреча у Заказчика была именно с коммерческим директором. Нас ознакомили с процессом производства, предоставили краткое видение Системы и проблемные участки внутренних процессов.
При обсуждении коммерческий директор делал все возможное, чтобы завести в тупик разработчиков. «А можно ли сделать так, а можно ли сделать этак, а если еще вот это или лучше это…» Причем о простых вещах реализации он и слышать не хотел, словно девиз «чем проще – тем лучше» был не его принцип. Складывалось впечатление, что сам Заказчик добивался от Исполнителя фразы «это невозможно!», чтобы не запускать разработку Системы.
Вторая встреча была с директором компании. На встречи стало ясно, что Система необходимо больше всего именно ему... «Чем проще – тем лучше», повторял Заказчик. «…Я хочу видеть картину всего, считать быстро прибыль, видеть остатки, издержки, и вычислять, кто у меня ворует…».
Авторское право не передавалось, код Системы Заказчик не выкупал, поэтому стоимость проекта была относительно небольшой. Проект имел все шансы, чтобы начаться, но окончательное слово коммерческого директора… и компания приняла решение, временно заморозить свои планы на Систему.
Если решение Заказчика, в целом как компанией, было принято на основе финансовой ситуации, которая возможно имела место, то тогда понимаешь, что Заказчик подошел к проблеме серьезно и взял время, чтобы обдумать или же найти более дешевые альтернативы. Но если причина решения внутренние выгоды отдельных участников, то не трудно догадаться, что в компании Система нужна только тому, кто ищет вора.
05.11.2009
Серенко Максим
Simplect™
Статья
Для производства конечной продукции Заказчиком используется некое оборудование и продукты. К основным затратам производства следует отнести затраты на продукты для конечной продукции, затраты на обслуживания техники и заработная плата рабочих.
Конечный производимый продукт имеет свойство возврата после его продажи поставщикам. Т.е. продав партию продукта поставщику, есть вероятность, что часть продукции снова вернется в компанию. Продукт, который вернули, снова попадает в цепь производства.
Как и в любой компании, в процессе производства участвуют несколько отделов и множество рабочих. И как часто бывает - проконтролировать все производство практически невозможно. Благодаря «нашему брату» часть начальной и даже конечной продукции пропадает без следа.
Кому, прежде всего, нужна Система, которая бы дала общую картину производства «на экране»? Ответ очевиден – владельцу компании.
Основной инициатор идеи завестись Системой – это директор. Второе лицо, которое принимает решения «интеграции» или даже запуска Системы – это коммерческий директор.
Первая встреча у Заказчика была именно с коммерческим директором. Нас ознакомили с процессом производства, предоставили краткое видение Системы и проблемные участки внутренних процессов.
При обсуждении коммерческий директор делал все возможное, чтобы завести в тупик разработчиков. «А можно ли сделать так, а можно ли сделать этак, а если еще вот это или лучше это…» Причем о простых вещах реализации он и слышать не хотел, словно девиз «чем проще – тем лучше» был не его принцип. Складывалось впечатление, что сам Заказчик добивался от Исполнителя фразы «это невозможно!», чтобы не запускать разработку Системы.
Вторая встреча была с директором компании. На встречи стало ясно, что Система необходимо больше всего именно ему... «Чем проще – тем лучше», повторял Заказчик. «…Я хочу видеть картину всего, считать быстро прибыль, видеть остатки, издержки, и вычислять, кто у меня ворует…».
Авторское право не передавалось, код Системы Заказчик не выкупал, поэтому стоимость проекта была относительно небольшой. Проект имел все шансы, чтобы начаться, но окончательное слово коммерческого директора… и компания приняла решение, временно заморозить свои планы на Систему.
Если решение Заказчика, в целом как компанией, было принято на основе финансовой ситуации, которая возможно имела место, то тогда понимаешь, что Заказчик подошел к проблеме серьезно и взял время, чтобы обдумать или же найти более дешевые альтернативы. Но если причина решения внутренние выгоды отдельных участников, то не трудно догадаться, что в компании Система нужна только тому, кто ищет вора.
05.11.2009
Серенко Максим
Simplect™
Статья
28 октября 2009 г.
Разработка ПО – это вам не макароны
К одному из моих партнеров обратилась компания по производству макаронных изделий с запросом «разработать Систему для контроля рабочих процессов в производстве».
Мой партнер обратился ко мне за помощью. Задачи мы распределили следующим образом, с заказчиком заключает договор он, разработка Системы закреплена также за ним. Мои обязанности - построение проектной документации.
Построение проектной документации – это первая фаза проекта, в которой принимает участие заказчик (сотрудники компании заказчика). В зависимости от объема задач и от интенсивности встреч данная фаза может длиться до 1 месяца и больше. В результате, на выходе заказчик получает документ, в котором описаны все его требования техническим языком.
После согласования и утверждения этого документа команда разработчиков приступает ко второй фазе – разработка Системы.
Кончено, если во время встреч будут присутствовать представители команды разработчиков, и они ни чем больше не заняты, то во время первой фазы разработчики могут делать заготовки, чтобы сократить время второй фазы.
Чтобы приступить к работе над первой фазой, я вынужден был ожидать, пока мой партнер подпишет договор с заказчиком и выставит ему первые счета за оплату работ первой фазы.
И тут начались прецеденты, которые не должны были коснуться разработчиков.
На одной из встреч с Заказчиком партнер согласился реализовать некий функционал, небольшую часть Системы, чтобы продемонстрировать Заказчику возможности будущей Системы. Заказчик сам попросил разработать ему определенную часть процесса, чтобы он мог оценить работу Исполнителя и качество, которое может дать Система. Партнер согласился, и сделал огромную ошибку проекта, которая повлияла финансово как на него, так и задержало начало проекта, а значит и коснулась Заказчика.
А именно, проект еще не начался, договор еще не заключили, деньги еще не оплатили, задачи не сформировали, но уже задействовали разработчиков. Т.е. проигнорировали юридическую сторону и первую фазу проекта.
Заказчику необходимо было объяснить, что в данном случае мы предоставляем услуги, которые нельзя сравнить с массовым товаром, например тем, что Вы производите. Что когда приходит к Вам клиент, и просит Вас предоставить ему пример изделия, перед тем как произвести заказ, Вы в состоянии предъявить товар, точную его копию, так как у Вас производство практически одинаковое, а вся продукция находится на складе, и для Вас не составит труда пойти и взять ее. Мы Вам можем предоставить аналогичный процесс, но только программу, которую мы Вам покажем, она будет совершенно иного направления. Вы хотите, чтобы мы запустили процесс производства, чтобы оценить качество товара, который может получиться. Мы не думаем, что Вы готовы будете сделать то же самое, если вместо макарон, Ваш клиент запросит у Вас запустить производство кукурузных палочек, при этом, не заключая контракта и не оплачивая расходов.
Отработанный процесс разработки программного обеспечения нельзя нарушать. Это сказывается как на Исполнителе, так и на Заказчике. Поэтому обе стороны должны понимать, что не нужно лепить из макарон кукурузные палочки, а то получится каша.
Статья
28.10.2009
Серенко Максим
Simplect™
Мой партнер обратился ко мне за помощью. Задачи мы распределили следующим образом, с заказчиком заключает договор он, разработка Системы закреплена также за ним. Мои обязанности - построение проектной документации.
Построение проектной документации – это первая фаза проекта, в которой принимает участие заказчик (сотрудники компании заказчика). В зависимости от объема задач и от интенсивности встреч данная фаза может длиться до 1 месяца и больше. В результате, на выходе заказчик получает документ, в котором описаны все его требования техническим языком.
После согласования и утверждения этого документа команда разработчиков приступает ко второй фазе – разработка Системы.
Кончено, если во время встреч будут присутствовать представители команды разработчиков, и они ни чем больше не заняты, то во время первой фазы разработчики могут делать заготовки, чтобы сократить время второй фазы.
Чтобы приступить к работе над первой фазой, я вынужден был ожидать, пока мой партнер подпишет договор с заказчиком и выставит ему первые счета за оплату работ первой фазы.
И тут начались прецеденты, которые не должны были коснуться разработчиков.
На одной из встреч с Заказчиком партнер согласился реализовать некий функционал, небольшую часть Системы, чтобы продемонстрировать Заказчику возможности будущей Системы. Заказчик сам попросил разработать ему определенную часть процесса, чтобы он мог оценить работу Исполнителя и качество, которое может дать Система. Партнер согласился, и сделал огромную ошибку проекта, которая повлияла финансово как на него, так и задержало начало проекта, а значит и коснулась Заказчика.
А именно, проект еще не начался, договор еще не заключили, деньги еще не оплатили, задачи не сформировали, но уже задействовали разработчиков. Т.е. проигнорировали юридическую сторону и первую фазу проекта.
Заказчику необходимо было объяснить, что в данном случае мы предоставляем услуги, которые нельзя сравнить с массовым товаром, например тем, что Вы производите. Что когда приходит к Вам клиент, и просит Вас предоставить ему пример изделия, перед тем как произвести заказ, Вы в состоянии предъявить товар, точную его копию, так как у Вас производство практически одинаковое, а вся продукция находится на складе, и для Вас не составит труда пойти и взять ее. Мы Вам можем предоставить аналогичный процесс, но только программу, которую мы Вам покажем, она будет совершенно иного направления. Вы хотите, чтобы мы запустили процесс производства, чтобы оценить качество товара, который может получиться. Мы не думаем, что Вы готовы будете сделать то же самое, если вместо макарон, Ваш клиент запросит у Вас запустить производство кукурузных палочек, при этом, не заключая контракта и не оплачивая расходов.
Отработанный процесс разработки программного обеспечения нельзя нарушать. Это сказывается как на Исполнителе, так и на Заказчике. Поэтому обе стороны должны понимать, что не нужно лепить из макарон кукурузные палочки, а то получится каша.
Статья
28.10.2009
Серенко Максим
Simplect™
7 сентября 2009 г.
КНИЖНЫЙ БЮДЖЕТ
Теоретические знания, подтвержденные практикой – это залог успеха любого проекта. Для того, чтобы получить прибыль, необходимо вложить ее в знания.
Книги для нас – это основной источник знаний. Мы стараемся не экономить на знаниях, так как от этого зависит качество проекта. В основном знания – это инструмент по сокращению времени проекта.
Средняя стоимость ИТ книги около 110 грн. Новые книги на 1200 стр., которые я называю «малополезные бочки», могут стоить до 350 грн. Такие книги полезно покупать один раз в 3 года. Новые «тонкие книги», ориентированные на более узкие задачи могут стоить до 100 грн. Если книга описывает новое направление, то стоимость таких книг может достигать до 200 грн.
Закупку книг мы делим на три вида: запланированная покупка для проекта, покупка для расширения уровня знаний (незапланированная) и покупка единицы.
Запланированная покупка
Часть проектного бюджета выделяется на покупку книг. Каждый новый проект подразумевает новую закупку книг. Выбор книг зависит от направления проекта. Мы стараемся обновить библиотеку, даже если книги такого направления уже есть. Правильно иметь в запасе несколько книг разных авторов по одному направлению. Обычно такая покупка состоит из 2 - 5 книг, бюджет от 250 грн. до 650 грн.
Незапланированная покупка
Данный вид покупки, мы используем несколько раз в год. Обычно это от 5 до 10 книг разных направлений. Бюджет такой закупки будет составлять от 500 грн. до 1100 грн.
Мы стараемся делать такие закупки перед запуском своего проекта, или же при открытии нового направления.
Покупка единицы
Выход новой книги, всегда соблазняет…
Итоги
Годовой запланированный книжный бюджет в среднем составляет 3500 грн.
При большом проектном наплыве годовой книжный бюджет может составить до 7000 грн.
Статья
07.09.2009
Серенко Максим
Simplect™
Книги для нас – это основной источник знаний. Мы стараемся не экономить на знаниях, так как от этого зависит качество проекта. В основном знания – это инструмент по сокращению времени проекта.
Средняя стоимость ИТ книги около 110 грн. Новые книги на 1200 стр., которые я называю «малополезные бочки», могут стоить до 350 грн. Такие книги полезно покупать один раз в 3 года. Новые «тонкие книги», ориентированные на более узкие задачи могут стоить до 100 грн. Если книга описывает новое направление, то стоимость таких книг может достигать до 200 грн.
Закупку книг мы делим на три вида: запланированная покупка для проекта, покупка для расширения уровня знаний (незапланированная) и покупка единицы.
Запланированная покупка
Часть проектного бюджета выделяется на покупку книг. Каждый новый проект подразумевает новую закупку книг. Выбор книг зависит от направления проекта. Мы стараемся обновить библиотеку, даже если книги такого направления уже есть. Правильно иметь в запасе несколько книг разных авторов по одному направлению. Обычно такая покупка состоит из 2 - 5 книг, бюджет от 250 грн. до 650 грн.
Незапланированная покупка
Данный вид покупки, мы используем несколько раз в год. Обычно это от 5 до 10 книг разных направлений. Бюджет такой закупки будет составлять от 500 грн. до 1100 грн.
Мы стараемся делать такие закупки перед запуском своего проекта, или же при открытии нового направления.
Покупка единицы
Выход новой книги, всегда соблазняет…
Итоги
Годовой запланированный книжный бюджет в среднем составляет 3500 грн.
При большом проектном наплыве годовой книжный бюджет может составить до 7000 грн.
Статья
07.09.2009
Серенко Максим
Simplect™
16 июня 2009 г.
Подготовка 5-й статьи для журнала
Закончена работа над пятой статьей для журнала "ПиКАД". Тема статьи будет звучать приблизительно так «Исполнение команд, речь и GPS навигация».
В этот раз статья будет состоять из трех тем «Робот: слушай, говори, слушайся…», «Робот, ты где?» и «Книги по Microsoft Robotics».
В этот раз статья будет состоять из трех тем «Робот: слушай, говори, слушайся…», «Робот, ты где?» и «Книги по Microsoft Robotics».
31 января 2009 г.
Обновление железа: резервирование данных
Для дополнительного резервирования данных было приобретено 2 жестких диска по 500 ГБ и 2 внешних кармана.
Таким образом, обеспечено быстрое резервирование и восстановление данных проекта.
4-я наша статья в журнале "ПиКАД"
Вышла 4-я наша статья в журнале "ПиКАД". Тема статьи "Microsoft Robotics Studio (исследование интерфейсов управления сервисами)".
Подписаться на:
Сообщения (Atom)
Сообщения
