プロダクトの非機能的な改善の工数をどう確保するか - yigarashiのブログ
プロダクトの非機能的な改善をビジネスの中でどのように進めるかは、多くのチームが頭を悩ませる課題であると思います。本記事では私が最近考えていることをまとめてみようと思います。主に自社プロダクトの継続開発を想定した議論をします。 前提 まず非機能改善について議論する上で、重要な前提がふたつあると思っています。 ひとつは、我々は常に共通の目標を持っているということです。プロダクトのミッションや期の目標のことです。ビジネスサイドの人もエンジニアも、そうした目標を達成するためにそこにいることに違いはありません。機能開発も非機能的な改善も、見ている時間軸が多少違うことはあれど、この目標を達成するための手段です。それらが一見対立するように見えるのは影響を与える指標が違うからです。 もうひとつは、非機能改善に「やらない」という選択肢はないということです。システムにはデフォルトで滅びる方向に力が加わっていま
サービスデザインの極意 機能を「シンプルにする」ことの難しさとは デザイン会社 ビートラックス: ブログ
足すより削る方が難しい。これはデザインをした者であれば誰もが直面したことのあるチャレンジだろう。現在のサービスデザインでは、足し算よりも引き算の方が何倍も重要である。 事実、現在ヒットしている商品やサービスのその多くが、機能の多さよりも必要最小限の機能でユーザーの目的を果たすことで人気を集めている。 リリース当初、Snapchatは、しばらくすると消えてしまう画像をユーザー同士で送り合うだけのアプリだった。Uberでは、タクシーの事前予約はできなかったし、Amazonは本だけを売っていた。 Googleは検索エンジンに過ぎなかったし、マクドナルドはフォークとナイフを提供していなかった。 たくさんのことがそれなりにできるよりも、ある一つのことを最高レベルの洗練された体験で提供することにフォーカスしているプロダクトに人々は熱狂する。それなのに、我々プロダクトチームの多くは、成功する製品には多く
エンジニアが事業に寄り添うことで、結果的に技術的負債が減る話 - エス・エム・エス エンジニア テックブログ
高齢社会に適した情報インフラを構築・提供する株式会社エス・エム・エスで、エンジニアをしている三田淳一です。2020年1月に入社し、介護事業者向け経営支援サービス『カイポケ』の開発を担当しています。 今回、エス・エム・エスの開発体制がどうなっているのか。開発体制が変わることによって、どのような変化が生まれているのかについて紹介していきたいと思います。 エンジニアと事業がフラットではない環境で生じる課題 ソフトウェアシステムの開発組織は、事業やサービスの企画・運営などを担う事業側からリクエストがエンジニアに下りてきて、エンジニアはそれに沿って開発するという、トップダウンのような構造になっていることがほとんどです。事業側とエンジニア側で、優劣がある状態ですね。 こうした環境では、自分のチームのメリット効率を優先して行動し、他のチームに対して非協力的になることも起こりやすくなります。例えば、事業側
ユーザーにとってどれだけ価値を提供できたかで生産性をお手軽に計測した話 - Qiita
はじめに あるプロダクトの開発チームの生産性を計測したいと思いました。 昔は、開発したソースコードの行数で生産性を計測していたと思います。ただ、ソースコードの行数では、正しく生産性は計測できないと言われています（例えばこちらの記事など）。 では生産性は、どうやって算出するのが良いのか、具体的な方法(そのまま真似できる方法)を探したのですが、見つからなくて困っていました。 ということで、生産性を計測する方法を考案して計測してみた結果、そこそこ良い効果があったので、その方法を紹介します。 成果とは何か [生産性] ＝ [成果] / [かかった工数] で算出する前提とします。ということで、まず成果とは何かを考えます。 たくさんソースコードを書いても、たくさん関数を作っても、たくさんデプロイしても、それが顧客の価値につながらなければ意味がないように思います。 だからファンクションポイント法や d/
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
