В пятницу не надо делать деплой просто потому, что в нашей работе баги — вещь обычная, а портить выходные никому не хочется. Да и устает человек к вечеру обычно. И помните, ваше время — бесценно. Лучше проведите вечер пятницы и выходные с семьей, или девушкой.
Для начинающего как раз «высокоуровневые языки» лучше. Никто ведь не хочет начинать с ассемблера? С++ тоже еще та жесть, сделайте оконное приложение, например, WinAPI. Но возьмите C# и например что-то типа WinForms — и человек получит «счастье» что у него получилось. Он может не думать, как ему сделать тулбар или кнопку, или диалог открытия файла, а решает задачу, пусть и детскую.
Позже жизнь расставит все по местам. Для применения инструмента не обязательно детально знать, как он сделан, на то оно и высокоуровневое программирование.
Когда статья «цепляет» электронный документооборот — это интересно, сам нахожусь в этой сфере разработки более 10 лет. Под этим термином и правда сейчас понимают больше «автоматизацию бизнеса», чем классику (автоматизация канцелярии). Но, как только мы ступаем в бизнес-процесс оказывается вот что:
1) общаясь с клиентами (заказчиком), я понял что рядовые сотрудники часто должны быть связаны по рукам и ногам, чтобы не сделать лишнего. Например, человек может создать документ, и отправить его по маршруту Пете-Васе-Коле-Оле. Но, зачем сотруднику это держать в голове? Раз — и используем жесткий маршрут, который заложил еще администратор, и все 100 сотрудников его используют. Это бюрократично, но это и есть «бизнес» — когда правит порядок а не разгильдяйство. И это разгружает голову людям — например, проще нажать одну кнопку и быть уверенным, что «Договор» пройдет сам нужные этапы, чем думать, кому и как его послать.
2) разработка систем такого рода на общей платформе — хорошо, но нужно сразу закладывать возможности по расширяемости. К вам придет крупный клиент, попросит доработать модуль, и т.п. Такие возможности серьезно удорожают разработку для вас, одно дело — законченный продукт «в коробке», который предоставляется как облако и никто не будет никому подключать ничего нового.
3) Какой командой вы создаете свой продукт, если не секрет? Например — «руководитель проекта — 1, программисты- 2, технический писатель -..., дизайнер......?»
Программировать легко и весело пока твоя задача не выходит на коммерческий уровень. А еще легче жить если ты никогда не увидишь (не будешь отвечать на вопросы) пользователей своей же системы. Типа программируешь — и все отлично! Наделал ошибок, программа неудобна — ну и ладно, заказчик же платит. Это удобная практика для «заокеанских заказов», где часто есть свой отдел саппорта, а также армия тестировщиков. Но возьмите вариант — «сам себе бизнесмен программист» — и вам придется и ТЗ составить, и общаться, и в ситуации «все пропало, помогите!» спасать клиента. Так что не все так весело.
Если вы администратор СЭД… я думаю вы уж сможете и потерять, и задним ввести. И еще много чего:) Применяйте цифровую подпись. Хотя от потери она не спасет. Тут надо, наверное, задуматься — каким образом сторонние люди (общественный контроль) будет следить за тем, не «мутят» ли админы или просто сотрудники что-то там в системе.
Можно бекапы базы выкладывать ежедневно в свободный доступ — пусть общественность себе копирует, все изучает, следит чтобы коррупционеры не «удалили» важные документы или не подправили. Но, не всегда все так легко, это скорее фантазии.
Общий код (а лучше общие проекты сборок .NET с полезными автономными классами, компонентами ) — это правильно. Они должны быть максимально автономными, чтобы крайне нечасто хотелось там что-то править или улучшать. Но если «форк» — кроме защиты от того что «в них ничего не сломали» вы получаете еще и эффект «ошибки живут вечно, пока вы не смержите их исправление».
А вот если один из проектов требует нечто такое, что уже «не лезет» на платформу, то вероятно, это тот случай, когда от платформы именно на этом проекте нужно отказаться.
Юнит-тесты спасут, но у кого есть желание-время-деньги их писать?
При внедрении документооборота не последний вопрос, который задает заказчик — «Сколько это будет мне стоить?». И да, работать еще не начали, даже не изучили список бизнес-процессов, а сумму уже неплохо бы «озвучить».
У вас в компании как вот с этим обстоят дела? Есть «калькулятор» стоимости, например?
Вот приходит к вам банк… и говорит — «Ну вот у нас порядка 1000 пользователей, кого надо автоматизировать, мы еще ничего не знаем, сколько стоит СЭД из коробки на 1000 ?» Потом идет согласование договора. Они пишут ТЗ, оно «кривое», но посылать клиента бесконечно на «доработку» тоже нельзя (потеряет интерес), и вот договор подписали. Примерно на 30 000 долларов:) Получить «100 000 — 500 000 $» при внедрении документооборота — это уже из разряда «фантастика», во всяком случае в Украине. Просто калибр затрат на IT такой ни один собственник не дает, а из гос-структур — там еще проблемнее.
В тексте написано: «Примите надлежащие меры, чтобы не допустить влияния рекламы на рейтинг вашего сайта в поисковых системах. Например, объявления Google AdSense и ссылки DoubleClick исключаются из сканирования в файле robots.txt ».
Теперь пример из жизни: есть сайт, на сайте баннер, около баннера текст «Покупайте наших слонов». Я не хочу чтобы эта фраза индексировалась, т.к. по сути это реклама. Вывод: сделаю размещение баннера из js-файла «на лету», и зарежу этот js-файл в robots.txt
В итоге — отображение для гугл-бота будет «без баннера», а для людей баннер будет.
Корректно ли это? Не будет ли пенальти? Баннер не adsense, считаем «свой собственный».
Сайт FossDoc конечно старенький, и мы тоже хотим его переделать. По поводу продуктов — тут тоже был большой вопрос: с одной стороны мы хотели дать людям выбор, да еще и возможность «отметить» галочками нужные им модули. Однако, такая практика привела к тому, что нам скорее позвонят и спросят, какой модуль им нужен, чем выберут сами.
Для FossLook мы уже отказались от идеи «выбери модули», и отобрали в него только самое необходимое, и цена там зависит только от числа клиентских мест — вычислить очень просто, и без вариантов.
Действительно, наши клиентские места долгое время были только десктопными, но сейчас есть и веб-доступ.
Разбить по календарному плану график оплат возможно, у нас был такой случай, когда заказчик покупал лицензии не сразу например 500 штук, а по 50 в течении 10 месяцев. Это было удобно, и нам, и ему, и главное мы видели, что он готов работать серьезно. Если бы все такие были заказчики, жизнь была бы намного проще.
Вот именно. Такие «номера» в ходу не только у гос.заказчиков, но и у частных организаций тоже. А какой калибр проектов был у вас, например? Хотя бы в общих чертах — что примерно внедряли, на сколько пользователей, много ли было бизнес-процессов? Очень интересно было бы узнать сколько времени потратили на составление ТЗ, или сколько прошло времени с момента «как начали» до момента «закрыли договор и получили деньги».
На самом деле у нас понятие «допиливание» — это не изменение существующего функционала. Весь коробочный функционал остается, а новое либо вписывается культурно (как новшество, которое будет полезно всем, либо новый модуль, новый плагин). Платформа при этом не меняется, и заказчик доволен.
По поводу аналитиков — конечно, такой человек необходим в любом случае, и он есть. Просто роль аналитика обычно выполняет человек с нашей стороны, а также есть один или несколько человек со стороны заказчика, которые объясняют, что хотят получить, и т.п.
1) Объявляется тендер. Туда «пихается» все — от поставки, до «в общем плане» например «Автоматизировать вот это»
2) договор сделают один — сам хотел бы разделить их на два, но нет (все умные, хотят «одним куском»)
3) итеративный подход хорошая штука, но деньги «выделяют» обычно один раз в год. И директор ИТ-департамента ДВА-три и более раз не ходит за деньгами. Так бы было чудно — спокойно запустили в работу систему «как есть» (из коробки), потом спокойно согласовали первый бизнес-процесс, оценили-заплатили-внедрили. Потом второй, десятый — все окей. Но так ни разу не делали — именно по причине что «наш клиент не может так платить»
4) договор должен быть закрыт — предоплата это да, допустим 30%. Но если это превращается в «резину» которая на годик, ничего хорошего в этом нет.
5) Доработки включают в договор… Но это «априори». Все равно что вас спросили «ааа… в здании нужен ремонт. Оцените, плиз, сразу, и да — стройматериалы тоже ваши». А вы такой — «Так он же очень разный бывает… и такой и сякой». А вам заказчик «Нуу… давайте примерно… как-нибудь этак-так». «И да, у нас бюджет ограничен в этом году… только вот в пределах этого»
Серьезно. Проекты очень разные (маленькие или большие — субъективный вопрос), и заказчики тоже. Хотите «документооборот» на 10 пользователей? Из коробки система может стоить...345 $. Это уже кое-что, для небольшого бизнеса. Нужно автоматизировать 500 пользователей? Это может стоить уже 26000 $. Как бы «миллион» никто не хочет выкладывать, людям нужны результаты, а деньги считают и экономят все.
Конечно. В идеальном мире, когда у заказчика есть желание нанять аналитика для себя со стороны, а этот аналитик бы изучил бизнес-процессы и предоставил оформленные требования — звучит логично и хорошо. Но кто его нанимает? Последний наш заказчик — это некий банк. Сотрудники его IT отдела выступают как аналитики, и ставят задачи (что хотят получить). Мы с ними общаемся, предлагаем варианты решения. Мы знаем что мы можем сделать «малой кровью», они знают «в общих чертах» что хотят получить. Почему именно «малой кровью»? Да потому что оплачивать рыночную стоимость человеко-часа программиста они не готовы. Месяц-два-три (2000 уе на 1 человека) — вылетает круглая сумма. Даже для банка.
Без программистов тут сложно обойтись. Во-первых такой «спец.должности» просто никто не держит, типа как «составитель ТЗ».
Кроме того, кто же лучше чем разработчик, знает аспекты, и может хотя бы оценить сложность проблемы… Стоит или не стоит в нее ввязываться, и т.п. Заказчик конечно хочет чтобы ему сделали «космический корабль», а задача составителя ТЗ убедить его в том, что ему хватит и автомобиля на ближайшие пару-тройку лет.
Позже жизнь расставит все по местам. Для применения инструмента не обязательно детально знать, как он сделан, на то оно и высокоуровневое программирование.
1) общаясь с клиентами (заказчиком), я понял что рядовые сотрудники часто должны быть связаны по рукам и ногам, чтобы не сделать лишнего. Например, человек может создать документ, и отправить его по маршруту Пете-Васе-Коле-Оле. Но, зачем сотруднику это держать в голове? Раз — и используем жесткий маршрут, который заложил еще администратор, и все 100 сотрудников его используют. Это бюрократично, но это и есть «бизнес» — когда правит порядок а не разгильдяйство. И это разгружает голову людям — например, проще нажать одну кнопку и быть уверенным, что «Договор» пройдет сам нужные этапы, чем думать, кому и как его послать.
2) разработка систем такого рода на общей платформе — хорошо, но нужно сразу закладывать возможности по расширяемости. К вам придет крупный клиент, попросит доработать модуль, и т.п. Такие возможности серьезно удорожают разработку для вас, одно дело — законченный продукт «в коробке», который предоставляется как облако и никто не будет никому подключать ничего нового.
3) Какой командой вы создаете свой продукт, если не секрет? Например — «руководитель проекта — 1, программисты- 2, технический писатель -..., дизайнер......?»
Можно бекапы базы выкладывать ежедневно в свободный доступ — пусть общественность себе копирует, все изучает, следит чтобы коррупционеры не «удалили» важные документы или не подправили. Но, не всегда все так легко, это скорее фантазии.
А вот если один из проектов требует нечто такое, что уже «не лезет» на платформу, то вероятно, это тот случай, когда от платформы именно на этом проекте нужно отказаться.
Юнит-тесты спасут, но у кого есть желание-время-деньги их писать?
У вас в компании как вот с этим обстоят дела? Есть «калькулятор» стоимости, например?
Вот приходит к вам банк… и говорит — «Ну вот у нас порядка 1000 пользователей, кого надо автоматизировать, мы еще ничего не знаем, сколько стоит СЭД из коробки на 1000 ?» Потом идет согласование договора. Они пишут ТЗ, оно «кривое», но посылать клиента бесконечно на «доработку» тоже нельзя (потеряет интерес), и вот договор подписали. Примерно на 30 000 долларов:) Получить «100 000 — 500 000 $» при внедрении документооборота — это уже из разряда «фантастика», во всяком случае в Украине. Просто калибр затрат на IT такой ни один собственник не дает, а из гос-структур — там еще проблемнее.
В тексте написано: «Примите надлежащие меры, чтобы не допустить влияния рекламы на рейтинг вашего сайта в поисковых системах. Например, объявления Google AdSense и ссылки DoubleClick исключаются из сканирования в файле robots.txt ».
Теперь пример из жизни: есть сайт, на сайте баннер, около баннера текст «Покупайте наших слонов». Я не хочу чтобы эта фраза индексировалась, т.к. по сути это реклама. Вывод: сделаю размещение баннера из js-файла «на лету», и зарежу этот js-файл в robots.txt
В итоге — отображение для гугл-бота будет «без баннера», а для людей баннер будет.
Корректно ли это? Не будет ли пенальти? Баннер не adsense, считаем «свой собственный».
Для FossLook мы уже отказались от идеи «выбери модули», и отобрали в него только самое необходимое, и цена там зависит только от числа клиентских мест — вычислить очень просто, и без вариантов.
Действительно, наши клиентские места долгое время были только десктопными, но сейчас есть и веб-доступ.
По поводу аналитиков — конечно, такой человек необходим в любом случае, и он есть. Просто роль аналитика обычно выполняет человек с нашей стороны, а также есть один или несколько человек со стороны заказчика, которые объясняют, что хотят получить, и т.п.
2) договор сделают один — сам хотел бы разделить их на два, но нет (все умные, хотят «одним куском»)
3) итеративный подход хорошая штука, но деньги «выделяют» обычно один раз в год. И директор ИТ-департамента ДВА-три и более раз не ходит за деньгами. Так бы было чудно — спокойно запустили в работу систему «как есть» (из коробки), потом спокойно согласовали первый бизнес-процесс, оценили-заплатили-внедрили. Потом второй, десятый — все окей. Но так ни разу не делали — именно по причине что «наш клиент не может так платить»
4) договор должен быть закрыт — предоплата это да, допустим 30%. Но если это превращается в «резину» которая на годик, ничего хорошего в этом нет.
5) Доработки включают в договор… Но это «априори». Все равно что вас спросили «ааа… в здании нужен ремонт. Оцените, плиз, сразу, и да — стройматериалы тоже ваши». А вы такой — «Так он же очень разный бывает… и такой и сякой». А вам заказчик «Нуу… давайте примерно… как-нибудь этак-так». «И да, у нас бюджет ограничен в этом году… только вот в пределах этого»
Кроме того, кто же лучше чем разработчик, знает аспекты, и может хотя бы оценить сложность проблемы… Стоит или не стоит в нее ввязываться, и т.п. Заказчик конечно хочет чтобы ему сделали «космический корабль», а задача составителя ТЗ убедить его в том, что ему хватит и автомобиля на ближайшие пару-тройку лет.