Гибкие методологии работают в условиях отсутствия лучших практик. В поддержке же они есть, их нужно накапливать и повторно использовать. Можно применять инструмент не по назначению, но это не даст лучший результат.
Для процессов есть ITIL и стандарты ISO. В ITIL подробно расписано как строить процессы.
Если кратко, то гибкие методологии придуманы для продуктов (мы не знаем на самом деле куда идем, нужно постоянно получать отклик рынка и менять направление движения), посредственно подходят для проектов (заказ сделать что-то в срок и объем) и не годятся для процессов (ака поддержка принтеров в рабочем состоянии).
Еще, если действительно нужна динамическая динамичность, то можно использовать динамические языки на платформе .net. Позволит проще/чище реализовать нужную динамичность. Не знаю насколько это Юнити поддерживает.
И наоборот, если даже делать универсальное хранилище для характеристик объектов, то апи доступа к ним стоит сделать типизированным (не object GetPropertyByName, а int GetLivesCount).
Про ооп vs коп: у вас в обоих случаях описывается ооп. Когда говорите об ооп подразумеваете наследование, а коп агрегацию. Действительно, обычно лучше агрегироваться, а не наследоваться. Коп — это уровень сборки приложения, когда у компонента есть не только код, но и данные и ui.
Для кругозора можно еще почитать про аспекты (ваши компоненты на них сильно похожи) и мультиагентное программирование.
Идея приёмной нормальная и очевидная. iMac странно выглядят, даже если «списанные». Нет дают чувства эффективности.
Сажать туда мегакомпетентных сотрудников или нет — вопрос спорный. Если не чаще раза в месяц на такого человека, то можно и полезно. Иначе неэффективное использование.
Решение самой частой проблемы (сброса пароля) — не очень. Сейчас, видимо списанные iMac? Только для того, чтобы ввести логин в веб-форму? В будущем ударопрочный киоск в офисе, еще и не у стенки? Посмотрите как в Икеи сделаны 4 рабочих места по кругу или по 1 рабочему месту, если 1 достаточно. Там думают об эффективности. Распечатка пароля на чековой ленте? Надеюсь одноразовый на смену пароля (и не отключает действие текущего до ввода одноразового, иначе можно «баловаться» сменой пароля другим людям). Конкретное решение предлагать бесполезно, т.к. не знаю всех деталей. Например, если смартфоны в гостевой или корпоративной сети, то вывесить сайт со сменой пароля туда (и поставить рядом с приемной табличку с инструкцией как менять пароль). Корпоративное приложение для мобильников, если есть, туда добавить функционал. Научить, что можно звонить на телефон, а там человек заполняет логин и отправляет форму. Сделать автоматический телефонный номер, если у сотрудников на бейдже есть номер, чтобы через цифровую клавиатуру телефона его ввести. Да мало ли вариантов.
Интересный фреймворк, поразбирался, но не нашел один момент про колонки.
Есть возможность делать динамические колонки (т.е. из данных берем содержимое и кол-во заголовков и столбцов)?
Аналогично, есть ли возможность делать полудинамические колонки (т.е. набор колонок известен, они заданы в дизайне, но могут в зависимости от параметров шаблона скрываться (например, группировка по разным полям))?
Пример неудачный. Это ошибка в программе. Есть способ определить, что в системе стоит платный аналог и запустить его или отключить рекламу по факту наличия приложения. А не проводить ликбезы пользователям. Любой ликбез пользователям — это недоработка самой программы.
Но требования в 1/3 дня конские для малоприбыльных программ (коих большинство).
Вы правда думаете, что обеспечите более стабильный сервис, чем специализированная процессинговая компания? Или дело в UI и/или стоимости услуг процессинга?
> А я всегда думал, что малый бизнес выживает только за счет высокой эффективности при меньшей норме прибыльности… А оказывается вся прибыль в малом бизнесе.
Как всё печально… Норма прибыльности (в процентах) у основных товаров/услуг у крупного бизнеса обычно ниже, чем у малого. Прибыль достигается объемами. Да и закупки для основных товаров/услуг дешевле. Персонала больше, он специализированный (IT-отдел вместо одного человека), поэтому при том же базовом уровне будет эффективность работ выше. Малый бизнес может:
1) уйти в подсегмент (продажа «деревенских» продуктов vs Пятерочка)
2) за счет точной подгонки товара/услуги продать ее дешевле, чем крупный, но заложить туда значительно меньше (это нормально, т.к. конкретному покупателю что не заложили не нужно; Paint.NET vs Photoshop).
> Конечно именно потому что деньги дорогие лучше покупать компьютеры по одному, каждый раз переплачивая в районе 3% стоимости за доставку, тратя времени на запрашивание счета и его оплату и не получая никаких скидок за объем. Ну и да, компьютеры в резерве — это тоже «зря потраченные деньги», т.к. в случае чего сотрудник может пару дней и не работать.
Какая доставка в компании на 100 человек? Я всю жизнь работаю в таких компаниях. Сис. админ или еще кто привозит на своей машине или даже на автобусе этот несчастный 1 комп. Компьютере в резерве в разных организациях решается по разному, но обычно без кучки новых неиспользуемых ПК на складе. 100 человек (для простоты и компов) в организации, в квартал вряд ли больше 10 компов купят, какие тут скидки за объем? Если брать не в b2b фирме, поставляющей брендированные ПК от компании HP по изначально большой цене, а в дискаунтере типа DNS. Счет в каком-нибудь DNS отдается на месте, оплата счета тоже без особых проблем (сейчас уже у всех клиент-банки). Да и относительную мелочь (1 комп.) можно за наличку покупать, если связываться со счетом и оплатой нет времени или желания. Основное здесь — это наличие свободных денег и уверенности, что оборудование действительно понадобится. Если открывается новый офис, идут собеседования nonstop, то понятно, что не по 1 компу стоит покупать.
> Да, но зачем? Почему нельзя сразу купить аппарат, у которого оригинальные расходные материалы и так будут по цене грязи?
Вы, видимо, нашли святой грааль печатника. И оригинальные картриджи дешевле заправки, и аппараты дешевле/лучше аналогов с дорогими картриджами. Несколько лет назад закупал кучу (больше 70, не помню уже точно) принтеров, смотрел варианты. Стоимость отпечатка с заправками и восстановлениями картриджей была сильно ниже оригинальных. Даже интересно что это за принтеры, может что изменилось или что пропустил.
> Вот тут не согласен в корне. Все же меняются бизнес-процессы — меняется структура хранения (и документируется). Нет никакого смысла каждый месяц проводить аудит файлового сервера — это беспощадно. Если у вас все сотрудники имеют право в корне файлового сервера создавать бесчисленное множество папок, то у вас файлопомойка, а не файловый сервер.
Так про корень и не говорилось. Ежемесячно — это пример, причем, как раз, для состояния активного роста компании. Меняются/уточняются бизнес-процессы, ну и файлы как их артефакты. Никто не говорит, что каждый месяц будут революционные изменения, но если не работать с изменениями, то вся ваша документация превратится из рабочего документа в неиспользуемую на практике формальность. Как раз наличие неожиданных файлов — это признак изменения бизнес-процесса (изменение нужно либо узаконить, либо пресечь).
> К сожалению, использование облачных технологий сейчас, в большинстве случаев, возможно вопреки всему, а не благодаря.
Мысль не раскрыта, только софистика какая-то. На практике используем не первый год множество сервисов, довольны, считаем что эффективно. Обычно 3 аргумента против:
1. безопасность — Гуглу/правительствам не нужны данные конторки на 100 человек, а от других защитит лучше, чем самостоятельно. Если нужны, то вы сильно необычная компания.
2. надежность (безотказность, не закроют сервис) — когда вы совсем маленькие, то фин. условия важнее, на бизнесе не скажется особо. Когда становитесь больше, то бекапы, бекапы и план переезда еще куда-нить в случае проблем.
3. стабильность интернета — тут индивидуально, у нас в Самаре инет не работает 1-2 дня в год, переход на это время на всякие 3/4G обычно достаточен.
> Напомните, пожалуйста, какая ответственность у облачных провайдеров предусмотрена за потерю данных? И как давно последний раз горел дата-центр?
На практике никакая. Так бекапы никто не отменял. С Ansible сервер без данных поднимается на любом новом (который сейчас не лежит) VPS за час, плюс время на восстановление данных из бекапа (перекачку, смотря сколько там Gb было). Все-таки для обычного малого бизнеса обеспечить физическую безопасность (от криминала и маски-шоу) серверов тяжело. Тем более они еще могут быть по железу либо б/у, либо обычный ПК. Так что облако надежнее, но бекапы никто не отменял.
Странная статья для хабра. Явно ориентирована на бизнес, а тут больше IT-ресурс.
По делу. Чем отличается малый бизнес от среднего и крупного? Низкой эффективностью и большой прибыльностью (чтобы покрыть низкую эффективность). Откуда она берется? Из большой неопределенности (реально непонятно что будет через год и будет ли компания вообще, набор товаров/услуг меняется чуть ли не под каждого клиента). Со временем неопределенности может становиться меньше, появляется специализация и рост в ней. Бывают и эффективные малые бизнесы (например, пекарня на углу), но там нет роста.
IT-системы в данном случае лишь повторяют то, что происходит со всей организацией. В статье даны сомнительные, если не сказать, что опасные рекомендации.
Да, нужно стараться уменьшать зоопарк. Но явно не стоит покупать компы раз в квартал. Всё может поменяться, да и денеги (кредиты) в России очень дорогие, лучше пусть работают.
Заправка картриджей — отлаженный процесс, явно можно ходить в белых рубашках (вам, видимо, как-то очень не везло).
Решения для малого бизнеса часто имеют своих «больших братьев» (софт), а железо можно ставить в отделения/отделы; зато идет серьезная экономия относительно покупки сразу больших братьев.
Да, нужно документировать настройки серверов и получать исходники программ (или сразу брать риск переделывать с нуля, что получается эффективней). Права доступа — обязательно, когда появляется сотрудник, отвечающий за ПК, до этого ничего страшного в этом нет. Да, бренды не решают. Но смысла что-то избыточное покупать тоже нет, если есть сомнение что вряд ли понадобится. Малой организации лучше использовать почту для домена Яндекса или biz МейлаРу, смысла поддерживать свой почтовый сервер нет (будет одновременно хуже и дороже).
С файлопомойкой не согласен. Никакие разовые действия тут не помогут. И придумывание «наперед». Этим нужно заниматься, например, ежемесячно: смотрится что получилось на диске, как изменились бизнес-процессы, придумывается новая организация файлов. В идеале, файлов много не должно быть: документы в системе документооборота, шаблоны не заполненные, отдельно заполненные по проектной и процессной деятельности.
В статье не увидел банальных, но далеко не всегда используемых рекомендаций:
1) Максимальное использование облачных сервисов. Это позволяет часто не покупать железо, не заниматься поддержкой. Часто они бесплатные. Те же Почта для домена Яндекса, документы и принтеры Гугла, файлы Dropbox (и всякие другие). Не забудем про CRM и task management. Сюда же и телефонию можно отнести (чтобы не привязываться к определенному физическому офису).
2) Облачные 1С: чтобы не украли вместе с компом, да и хранение в облаке понадежней.
3) Бекапы. В частности, должно быть понятно как будет восстановлено всё, что нужно.
Похоже, что просто никто не применяет суперкомпьютеры для этого. Просто никому этот го не сдался. Какой-то одиночка без серьезного финансирования (сравните с IBM) время от времени выпускает свою программу. Для тех же шахмат наверняка не один человек программу писал и мощности вычислительные соответствующие.
В Самаре есть областное предприятие с кучей 3Д-принтеров (и порошковые, и рапы) и бесплатным доступом к ним. По крайней мере так рекламировалось. Лазерную резку тоже вполне можно найти (универы и заводы присутствуют).
Вот только никакого смысла делать электронику в России нет. С одной стороны производится они будут в Китае (Экономически невыгодно производить что-то материальное в России; за исключением таких вещей как бетон), неудобно подбирать китайские компоненты в России. Проще в нормальный хакспейс в Китае отправиться, если уж так хочется товарами заняться. И чтобы через дорогу был мегамагазин комплектухи (вроде как на Хабре была статься про что-то подобное).
С другой стороны если говорить про путь США (маркетинг и дизайн местный, производство Китай), то тоже особо нечем похвастаться. Дизайн вскоре после октябрской революции разгромили. Школы промышленного дизайна у нас нет, есть отдельный интересующиеся личности.
Хакспейс в России — исключительно хобби. Через эту призму можно что-то сделать (клуб для любителей попоять собственный умный дом), но дело неблагодарное.
Хромкаст сейчас в России фактически — это только Youtube. VK и IVI (на iOS) его не поддерживают. Не припомню и более мелких сайтов которые его поддерживают. Есть всякие плагины для браузера Chrome, чтобы найти видео на странице в mp4 и проиграть его, но с видеосервисами российскими оно не работает. Трансляция вкладки браузера для презентации пойдет, а видео не очень, притормаживает (хотя может зависеть от мощности компа).
Если хочется видео с сайтов (VK, IVI и прочие), то до сих пор это FLASH, а для стиков означает Android.
Дреби интересен как концепция. Довольно много интересных вещей сделано правильно. Но (со стороны) ему еще очень далеко до production. Не хватает самых банальных и скучных вещей (в скобка ссылки на некоторые rails-библиотеки):
1) Пример регистрации/логина/ограниченного изменения ресурсов. До livedb 0.4 вообще не было возможности работать с отдельными полями. Как теперь — может и есть, нужно изучать что именно там добавили.
2) Деплой. По типу cap production deploy
3) Миграции БД вперед и назад.
4) Что там с тестами.
5) Настройка Ubuntu LTS с нуля на эту штуку.
6) Мониторинг производительности.
7) Какие там логи и как их можно анализировать (gem 'request-log-analyzer')
8) Как в режиме разработки фреймворк реагирует на 500ую серверную ошибку. gem 'better_errors'
9) Как идет работа с отправкой почты и ее отладкой
10) Как вообще с фоновыми задачами обстоят дела (gem 'sidekiq')
11) Какие-нибудь бест-практики, хоть немного
12) Как документировать АПИ, БД и другое
13) Какие-то аналоги asset pipeline (объединение и преобразование js, css, png)
14) Шаблон проекта с бутстрапом
15) Поддерживаются ли HAML, SASL, Coffescript или аналоги
16) Интеграция с cron-задачами (gem 'whenever')
17) Как разработчик оповещается об ошибках в продакшене (gem 'exception_notification')
18) Как задаются настройки приложения (в каких-нибудь yaml-файлах)
19) Как делаются переводы приложения (хотя бы ru/en как минимум)
и т.п.
Этих материалов не видел и на англ. языке.
Когда эти вещи будут задокументированы (а в большинстве случаев еще и написаны/портированы), тогда можно будет говорить о Derby как фреймфорке для production. Сейчас же ИМХО только там где без него получается намного тяжелее, т.е. мало где.
Во всём этом пугает то, что фреймворком занимается только 1 человек. И тот не особо регулярно, судя по комитам.
В чем проблема? Практически всё что «производится» в России (тем более из электроники) приходит из Китая. Вопрос в цене, качестве и глубине доработок от базовой китайской модели. И всё это считается российской разработкой. Как и российские машины BMW.
Без кардинального изменения в регулировании другого не будет (см. детали в известном открытом письме о том, почему тракторы делают в Канаде).
В Москве год или два назад узнавал сколько стоит собранный принтер (обычный «самопечатающийся» рап что-то там). Было что-то около 60-80тр. Здесь дешевле. И есть гарантия. Для Воронежа и окрестностей отличный вариант. В 1,5 раза дороже чем в Китае — тоже хороший показатель (если это так и для принтера, обычно в России в 3 раза дороже оптовых китайских цен). Особенно, если учесть «замечательную» таможню (вспомним знаменитый пост о растаможке 3д-принтера из Китая), все налоги и гарантию на устройство.
Да, модель явно чужая. При этом некоторые детали могут производится и в России (например, разные железки). Лишь бы в этом был экономический смысл. Можно даже при желании набрать те самые 70% (по количеству или весу, например).
Создается впечатление, что автор не владеет терминологией (российский товар) и слишком верит в маркетинг (большинство деталей — по какому критерию и сколько не уточнялось). Рад за Воронеж.
Принципы в статье можно разделить на 2 части: ответственное отношение сотрудника к работе (пп. 3-10) и правила использования ХХХ (пп. 1, 2, 11-13).
При соотношении 25 чел. в команде на одного менеджера без ХХХ никуда, менеджер не может помнить кто и что делает. Если работы в проекте достаточно сильно связаны, то так же без активного использования ХХХ вообще никак. Скорее всего, проект классический водопадный (фиксированы сроки, функционал, качество и стоимость) и даже реализуется без внутреннего agile, поэтому требование к полноте задач (п.12) и отсутствие правил про релизы/итерации. Тут есть что развивать, но при достаточном допуске по стоимости и времени можно и так успешно завершать проекты.
По принципам формулировки грубоваты. Но по сути хорошо, если сотрудник будет до последнего скрывать проблемы по задаче (п.5)? Или приходить к руководителю только с эмоциями, без предварительного самостоятельного анализа из-за чего они (п.9)? Или втихаря сделать не то, что просили (интерпретировав как понравилось) (п.8)? Это не имеет никакого отношения к ограничению творчества (как писали в комментариях ниже). Фактически, пункты 3-10 можно переформулировать как «оперативно обсуждайте проблемы вместо молчания». Адекватное поведение взрослого человека, который не хочет подставить своего руководителя.
В прошлом году был на стенде Samsung, там были планшетники в типа киоск режиме. Железные кнопки отключены не были. По крайней мере организаторы стенда никакие хитрые API для киоска не использовали. Был разочарован.
Если киоск, то либо iOS, либо рутовать и «хачить», приличных вариантов нет.
Для процессов есть ITIL и стандарты ISO. В ITIL подробно расписано как строить процессы.
Если будут проблемы в связке smpp/ruby, то можно посмотреть в сторону Kannel.
Ps. 3G от билайна работал хорошо.
И наоборот, если даже делать универсальное хранилище для характеристик объектов, то апи доступа к ним стоит сделать типизированным (не object GetPropertyByName, а int GetLivesCount).
Для кругозора можно еще почитать про аспекты (ваши компоненты на них сильно похожи) и мультиагентное программирование.
Сажать туда мегакомпетентных сотрудников или нет — вопрос спорный. Если не чаще раза в месяц на такого человека, то можно и полезно. Иначе неэффективное использование.
Решение самой частой проблемы (сброса пароля) — не очень. Сейчас, видимо списанные iMac? Только для того, чтобы ввести логин в веб-форму? В будущем ударопрочный киоск в офисе, еще и не у стенки? Посмотрите как в Икеи сделаны 4 рабочих места по кругу или по 1 рабочему месту, если 1 достаточно. Там думают об эффективности. Распечатка пароля на чековой ленте? Надеюсь одноразовый на смену пароля (и не отключает действие текущего до ввода одноразового, иначе можно «баловаться» сменой пароля другим людям). Конкретное решение предлагать бесполезно, т.к. не знаю всех деталей. Например, если смартфоны в гостевой или корпоративной сети, то вывесить сайт со сменой пароля туда (и поставить рядом с приемной табличку с инструкцией как менять пароль). Корпоративное приложение для мобильников, если есть, туда добавить функционал. Научить, что можно звонить на телефон, а там человек заполняет логин и отправляет форму. Сделать автоматический телефонный номер, если у сотрудников на бейдже есть номер, чтобы через цифровую клавиатуру телефона его ввести. Да мало ли вариантов.
Есть возможность делать динамические колонки (т.е. из данных берем содержимое и кол-во заголовков и столбцов)?
Аналогично, есть ли возможность делать полудинамические колонки (т.е. набор колонок известен, они заданы в дизайне, но могут в зависимости от параметров шаблона скрываться (например, группировка по разным полям))?
Но требования в 1/3 дня конские для малоприбыльных программ (коих большинство).
Как всё печально… Норма прибыльности (в процентах) у основных товаров/услуг у крупного бизнеса обычно ниже, чем у малого. Прибыль достигается объемами. Да и закупки для основных товаров/услуг дешевле. Персонала больше, он специализированный (IT-отдел вместо одного человека), поэтому при том же базовом уровне будет эффективность работ выше. Малый бизнес может:
1) уйти в подсегмент (продажа «деревенских» продуктов vs Пятерочка)
2) за счет точной подгонки товара/услуги продать ее дешевле, чем крупный, но заложить туда значительно меньше (это нормально, т.к. конкретному покупателю что не заложили не нужно; Paint.NET vs Photoshop).
> Конечно именно потому что деньги дорогие лучше покупать компьютеры по одному, каждый раз переплачивая в районе 3% стоимости за доставку, тратя времени на запрашивание счета и его оплату и не получая никаких скидок за объем. Ну и да, компьютеры в резерве — это тоже «зря потраченные деньги», т.к. в случае чего сотрудник может пару дней и не работать.
Какая доставка в компании на 100 человек? Я всю жизнь работаю в таких компаниях. Сис. админ или еще кто привозит на своей машине или даже на автобусе этот несчастный 1 комп. Компьютере в резерве в разных организациях решается по разному, но обычно без кучки новых неиспользуемых ПК на складе. 100 человек (для простоты и компов) в организации, в квартал вряд ли больше 10 компов купят, какие тут скидки за объем? Если брать не в b2b фирме, поставляющей брендированные ПК от компании HP по изначально большой цене, а в дискаунтере типа DNS. Счет в каком-нибудь DNS отдается на месте, оплата счета тоже без особых проблем (сейчас уже у всех клиент-банки). Да и относительную мелочь (1 комп.) можно за наличку покупать, если связываться со счетом и оплатой нет времени или желания. Основное здесь — это наличие свободных денег и уверенности, что оборудование действительно понадобится. Если открывается новый офис, идут собеседования nonstop, то понятно, что не по 1 компу стоит покупать.
> Да, но зачем? Почему нельзя сразу купить аппарат, у которого оригинальные расходные материалы и так будут по цене грязи?
Вы, видимо, нашли святой грааль печатника. И оригинальные картриджи дешевле заправки, и аппараты дешевле/лучше аналогов с дорогими картриджами. Несколько лет назад закупал кучу (больше 70, не помню уже точно) принтеров, смотрел варианты. Стоимость отпечатка с заправками и восстановлениями картриджей была сильно ниже оригинальных. Даже интересно что это за принтеры, может что изменилось или что пропустил.
> Вот тут не согласен в корне. Все же меняются бизнес-процессы — меняется структура хранения (и документируется). Нет никакого смысла каждый месяц проводить аудит файлового сервера — это беспощадно. Если у вас все сотрудники имеют право в корне файлового сервера создавать бесчисленное множество папок, то у вас файлопомойка, а не файловый сервер.
Так про корень и не говорилось. Ежемесячно — это пример, причем, как раз, для состояния активного роста компании. Меняются/уточняются бизнес-процессы, ну и файлы как их артефакты. Никто не говорит, что каждый месяц будут революционные изменения, но если не работать с изменениями, то вся ваша документация превратится из рабочего документа в неиспользуемую на практике формальность. Как раз наличие неожиданных файлов — это признак изменения бизнес-процесса (изменение нужно либо узаконить, либо пресечь).
> К сожалению, использование облачных технологий сейчас, в большинстве случаев, возможно вопреки всему, а не благодаря.
Мысль не раскрыта, только софистика какая-то. На практике используем не первый год множество сервисов, довольны, считаем что эффективно. Обычно 3 аргумента против:
1. безопасность — Гуглу/правительствам не нужны данные конторки на 100 человек, а от других защитит лучше, чем самостоятельно. Если нужны, то вы сильно необычная компания.
2. надежность (безотказность, не закроют сервис) — когда вы совсем маленькие, то фин. условия важнее, на бизнесе не скажется особо. Когда становитесь больше, то бекапы, бекапы и план переезда еще куда-нить в случае проблем.
3. стабильность интернета — тут индивидуально, у нас в Самаре инет не работает 1-2 дня в год, переход на это время на всякие 3/4G обычно достаточен.
> Напомните, пожалуйста, какая ответственность у облачных провайдеров предусмотрена за потерю данных? И как давно последний раз горел дата-центр?
На практике никакая. Так бекапы никто не отменял. С Ansible сервер без данных поднимается на любом новом (который сейчас не лежит) VPS за час, плюс время на восстановление данных из бекапа (перекачку, смотря сколько там Gb было). Все-таки для обычного малого бизнеса обеспечить физическую безопасность (от криминала и маски-шоу) серверов тяжело. Тем более они еще могут быть по железу либо б/у, либо обычный ПК. Так что облако надежнее, но бекапы никто не отменял.
По делу. Чем отличается малый бизнес от среднего и крупного? Низкой эффективностью и большой прибыльностью (чтобы покрыть низкую эффективность). Откуда она берется? Из большой неопределенности (реально непонятно что будет через год и будет ли компания вообще, набор товаров/услуг меняется чуть ли не под каждого клиента). Со временем неопределенности может становиться меньше, появляется специализация и рост в ней. Бывают и эффективные малые бизнесы (например, пекарня на углу), но там нет роста.
IT-системы в данном случае лишь повторяют то, что происходит со всей организацией. В статье даны сомнительные, если не сказать, что опасные рекомендации.
Да, нужно стараться уменьшать зоопарк. Но явно не стоит покупать компы раз в квартал. Всё может поменяться, да и денеги (кредиты) в России очень дорогие, лучше пусть работают.
Заправка картриджей — отлаженный процесс, явно можно ходить в белых рубашках (вам, видимо, как-то очень не везло).
Решения для малого бизнеса часто имеют своих «больших братьев» (софт), а железо можно ставить в отделения/отделы; зато идет серьезная экономия относительно покупки сразу больших братьев.
Да, нужно документировать настройки серверов и получать исходники программ (или сразу брать риск переделывать с нуля, что получается эффективней). Права доступа — обязательно, когда появляется сотрудник, отвечающий за ПК, до этого ничего страшного в этом нет. Да, бренды не решают. Но смысла что-то избыточное покупать тоже нет, если есть сомнение что вряд ли понадобится. Малой организации лучше использовать почту для домена Яндекса или biz МейлаРу, смысла поддерживать свой почтовый сервер нет (будет одновременно хуже и дороже).
С файлопомойкой не согласен. Никакие разовые действия тут не помогут. И придумывание «наперед». Этим нужно заниматься, например, ежемесячно: смотрится что получилось на диске, как изменились бизнес-процессы, придумывается новая организация файлов. В идеале, файлов много не должно быть: документы в системе документооборота, шаблоны не заполненные, отдельно заполненные по проектной и процессной деятельности.
В статье не увидел банальных, но далеко не всегда используемых рекомендаций:
1) Максимальное использование облачных сервисов. Это позволяет часто не покупать железо, не заниматься поддержкой. Часто они бесплатные. Те же Почта для домена Яндекса, документы и принтеры Гугла, файлы Dropbox (и всякие другие). Не забудем про CRM и task management. Сюда же и телефонию можно отнести (чтобы не привязываться к определенному физическому офису).
2) Облачные 1С: чтобы не украли вместе с компом, да и хранение в облаке понадежней.
3) Бекапы. В частности, должно быть понятно как будет восстановлено всё, что нужно.
Вот только никакого смысла делать электронику в России нет. С одной стороны производится они будут в Китае (Экономически невыгодно производить что-то материальное в России; за исключением таких вещей как бетон), неудобно подбирать китайские компоненты в России. Проще в нормальный хакспейс в Китае отправиться, если уж так хочется товарами заняться. И чтобы через дорогу был мегамагазин комплектухи (вроде как на Хабре была статься про что-то подобное).
С другой стороны если говорить про путь США (маркетинг и дизайн местный, производство Китай), то тоже особо нечем похвастаться. Дизайн вскоре после октябрской революции разгромили. Школы промышленного дизайна у нас нет, есть отдельный интересующиеся личности.
Хакспейс в России — исключительно хобби. Через эту призму можно что-то сделать (клуб для любителей попоять собственный умный дом), но дело неблагодарное.
Если хочется видео с сайтов (VK, IVI и прочие), то до сих пор это FLASH, а для стиков означает Android.
1) Пример регистрации/логина/ограниченного изменения ресурсов. До livedb 0.4 вообще не было возможности работать с отдельными полями. Как теперь — может и есть, нужно изучать что именно там добавили.
2) Деплой. По типу cap production deploy
3) Миграции БД вперед и назад.
4) Что там с тестами.
5) Настройка Ubuntu LTS с нуля на эту штуку.
6) Мониторинг производительности.
7) Какие там логи и как их можно анализировать (gem 'request-log-analyzer')
8) Как в режиме разработки фреймворк реагирует на 500ую серверную ошибку. gem 'better_errors'
9) Как идет работа с отправкой почты и ее отладкой
10) Как вообще с фоновыми задачами обстоят дела (gem 'sidekiq')
11) Какие-нибудь бест-практики, хоть немного
12) Как документировать АПИ, БД и другое
13) Какие-то аналоги asset pipeline (объединение и преобразование js, css, png)
14) Шаблон проекта с бутстрапом
15) Поддерживаются ли HAML, SASL, Coffescript или аналоги
16) Интеграция с cron-задачами (gem 'whenever')
17) Как разработчик оповещается об ошибках в продакшене (gem 'exception_notification')
18) Как задаются настройки приложения (в каких-нибудь yaml-файлах)
19) Как делаются переводы приложения (хотя бы ru/en как минимум)
и т.п.
Этих материалов не видел и на англ. языке.
Когда эти вещи будут задокументированы (а в большинстве случаев еще и написаны/портированы), тогда можно будет говорить о Derby как фреймфорке для production. Сейчас же ИМХО только там где без него получается намного тяжелее, т.е. мало где.
Во всём этом пугает то, что фреймворком занимается только 1 человек. И тот не особо регулярно, судя по комитам.
Без кардинального изменения в регулировании другого не будет (см. детали в известном открытом письме о том, почему тракторы делают в Канаде).
В Москве год или два назад узнавал сколько стоит собранный принтер (обычный «самопечатающийся» рап что-то там). Было что-то около 60-80тр. Здесь дешевле. И есть гарантия. Для Воронежа и окрестностей отличный вариант. В 1,5 раза дороже чем в Китае — тоже хороший показатель (если это так и для принтера, обычно в России в 3 раза дороже оптовых китайских цен). Особенно, если учесть «замечательную» таможню (вспомним знаменитый пост о растаможке 3д-принтера из Китая), все налоги и гарантию на устройство.
Да, модель явно чужая. При этом некоторые детали могут производится и в России (например, разные железки). Лишь бы в этом был экономический смысл. Можно даже при желании набрать те самые 70% (по количеству или весу, например).
Создается впечатление, что автор не владеет терминологией (российский товар) и слишком верит в маркетинг (большинство деталей — по какому критерию и сколько не уточнялось). Рад за Воронеж.
При соотношении 25 чел. в команде на одного менеджера без ХХХ никуда, менеджер не может помнить кто и что делает. Если работы в проекте достаточно сильно связаны, то так же без активного использования ХХХ вообще никак. Скорее всего, проект классический водопадный (фиксированы сроки, функционал, качество и стоимость) и даже реализуется без внутреннего agile, поэтому требование к полноте задач (п.12) и отсутствие правил про релизы/итерации. Тут есть что развивать, но при достаточном допуске по стоимости и времени можно и так успешно завершать проекты.
По принципам формулировки грубоваты. Но по сути хорошо, если сотрудник будет до последнего скрывать проблемы по задаче (п.5)? Или приходить к руководителю только с эмоциями, без предварительного самостоятельного анализа из-за чего они (п.9)? Или втихаря сделать не то, что просили (интерпретировав как понравилось) (п.8)? Это не имеет никакого отношения к ограничению творчества (как писали в комментариях ниже). Фактически, пункты 3-10 можно переформулировать как «оперативно обсуждайте проблемы вместо молчания». Адекватное поведение взрослого человека, который не хочет подставить своего руководителя.
Если киоск, то либо iOS, либо рутовать и «хачить», приличных вариантов нет.