Amazon

2011年7月31日日曜日

プロダクトマネージメント(4) -プロダクトマネジメント vs. エンジニアリング-



"Inspired日本語版第5章　プロダクトマネジメント vs. エンジニアリング"より

ソリューションを決めるのはプロダクトマネージャーだが、実際に何ができるかをいちばんよく知っているのはエンジニアリングチームであって、最終的には、エンジニアがソリューションを提供しなければならない。

プロダクトマネージャーがより優れた製品の着想を得るためにエンジニアの助けを借りる3つの方法

1. エンジニアをユーザーや客先の前に連れ出すこと。ユーザーが苦労する様子を直接に見ることで多くのことを学べるだけでなく、問題点とその深刻さをもっとよ く理解できるようになる。これをヒントにして、もっと優れたアイデアや解決策を思いつくことも多い。この方法は、エンジニアをプロトタイプの検証に連れて くることで、すぐに実行に移せるはずだ。

2. 技術が発展することで何ができるようになったかを探るために、エンジニアの助けを求めること。今使える技術やいずれ使えるようになりそうな技術としてどういうものがあるか、それらが目先の問題の解決にどう役立つか、ブレインストーミングをやる。

3. エンジニアみんな (それが無理なら、主任エンジニアだけでも) あるいはアーキテクトを、製品開発の初めの段階から関与させて、早い段階でそれぞれのアイデアについて必要な費用を見積もっておき、より望ましいソリュー ションを決めるのに役立てること。プロダクトマネージャーがよく起こす間違いとして、すばらしい製品の定義を思いついて、それをエンジニアリングチームに 丸投げしてしまう、というのがある。そのせいで、何をしたいかと何ができるのかをすり合わせるという非常に重要な作業に取りかかるのが遅れて、いろいろな 情報をしっかり検討する時間もないまま意思決定をしなければならない状況に陥ってから、慌ててすり合わせをする羽目になる。


離れたところにいる開発チームといっしょに仕事をすることになった場合には、開発をうまくやり遂げる確率を劇的に上げるためにプロダクトマネージャーができる 3つのこと

1. 開発チームと離れていればいるほど、また、言葉や文化や時差のためにコミュニケーション上の課題が大きければ大きいほど、製品仕様を決める段階でしっかり 完璧に作業しておく必要性に、いっそう強く迫られることになる。プロジェクトとして最悪なのは、プロダクトマネージャーが何を作りたいのかよくわかってい ない (あるいは、コロコロ考えを変える) ために、離れたところで作業しているチームがもがき苦しむことだ。

2. 開発チームのみんなが近くにいる場合には、複数の人が原因となる衝突 (たとえば、2人のマネージャーが別々の指示を出す場合) は、普通にしていても目に入るので、すぐ解決できる。開発チームが遠くにいる場合には、頭にくるようなことが寝耳に水で山ほど起こるかもしれない、と覚悟 しなければならない。そして、食い違いに気づくまでに、文字通り何ヶ月もかかるだってあるだろう。こういうことになるのは、だいたいは、離れたところにい る開発者たちが、だれが何をどうしろと言っているのか、さまざまな指示をどう解釈すればいいのかなどを、推測しなければならない羽目になるからだ。当然、 こういう推測がいつも当たっているとは限らない。本拠地にいるだれかに、遠くにいるチームとのすべての調整を任せることが、どうしても必要になる。すべて のやりとりはこの人を通さなければならないということではないが、エンジニアリングチームが説明や報告をしなければならない相手はだれであるかがあやふや ではダメだ、ということである。この調整をやるのは、場合によって、プロジェクトマネージャーだったり、エンジニアリングチームの上の方の人でプロダクト マネージャーの近くにいる人だったりするだろう。

3. 今は、多くの会社で、社内で使える優れたコミュニケーションの仕組みをいろいろと整えている。電子メールやインスタントメッセージのほかに、テレビ会議の 技術もものすごくよくなっているし、VoIP のおかげで国際通話料もずいぶん安くなった。そうは言っても、やはり、直接顔を合わせて話せる態勢にできるなら、それに代わるものはない。プロダクトマ ネージャーは、少なくとも 3ヶ月に一度は、エンジニアリングチームのところに出向いて、彼らとしっかり顔合わせをして、中心となっているアーキテクトやマネージャーと打合せをする べきだ。実際に訪問して直接顔を合わせることで、離れ離れのメンバーとの関係やコミュニケーションはずっとよくなるだろう。コミュニケーションを向上させ る他の方法としては、人材交流制度を作って、主な開発者をプロダクトマネージャーのもとに一定の期間派遣する、という手もある。


投稿者 時刻: 0 件のコメント:
ラベル:

フィーチャーフォンのアプリを作る際の注意点





Perlで作るモバイルサイトのコツ 　より

・文字コード

携帯用サイトの構築を行う場合にはWebアプリケーション内部ではUTF-8を使用し、出力の際にはShift_JISを使用できるようにUTF-8とShift_JISを相互変換する処理を実装する必要があります。

・キャリアに応じたXHTMLの出力

キャリアの仕様


・セッション管理

セッション管理は、ユーザーからのリクエストごとに一意のID（セッションID）を発行し、常にそのIDをリクエストに含ませることで行います。 PCであればクッキーを使用してセッションIDをブラウザに保持しておくことができますが、前述したとおり携帯ではクッキーを使用できる端末が限られるた め、画面遷移時にセッションIDを直接リクエストのパラメータとして渡す必要があります。

　パラメータを引き継ぐ必要のある遷移のパターンは以下の3つです。

  1. リンクによる遷移
  2. フォームによる遷移
  3. リダイレクトによる遷移

 

○PythonでUser Agentの値を取得する

http://d.hatena.ne.jp/perezvon/20080919/1221844404

logging.info(dir(self.request))でuser_agentというプロパティ 

# it works!
self.request.user_agentを使う
 
○User Agentの値を表示するPythonサンプル 
 
from google.appengine.ext import webapp
from google.appengine.ext.webapp.util import run_wsgi_app

class Receiver(webapp.RequestHandler):
  def get(self):
    self.response.out.write(
    """
    <html>
      <body>
        <b>%s</b>
      </body>
    </html>
    """ % self.request.user_agent)
    
    
application = webapp.WSGIApplication([
  ("/", Receiver)
], debug=True)

def main():
  run_wsgi_app(application)

if __name__ == "__main__":
  main() 
 
 
○Google App Engine for Pythonでのセッション管理の実装
セッション管理部分のみ抜粋


def getSession(request):
# クッキーのセッションIDとmemcache/Datastoreのセッション情報を照合する関数
# リクエストハンドラーのself.requestを引数として受け取る

    # クッキーからセッション番号を取得
    sid = request.cookies.get('SID', '')
    if sid:
        # まずmemcacheにそのセッション番号があるか探す
        session = memcache.get(sid)
        if session:
            return session

        # memcacheになければDatastoreから探す
        else:
            session = Session.get(sid)
            if session:
                # Datastoreにあればmemcacheにも入れておく
                memcache_key = str(session.key())
                memcache_value = {
                    'user' : {
                        'key' : str(session.user.key()),
                        'name' : session.user.name,
                    },
                }
                memcache.add(key=memcache_key, value=memcache_value, time=3600)

                return session
 
○Google App EngineでDjangoのテンプレートエンジンを使う
import wsgiref.handlers
from google.appengine.ext import webapp

#テンプレートを使用するため、下記二つのimportを追加
import os
from google.appengine.ext.webapp import template

class MainHandler(webapp.RequestHandler):

    def get(self):
        #テンプレートに渡す果物リスト
        fruits = ('みかん','りんご','バナナ','パイナップル','スイカ')
        #テンプレートに渡す文字列
        j_str = '日本語文字列';
        
        #連想配列にテンプレートに渡す値を設定
        #テンプレートからは、連想配列のキーでアクセスする。
        template_values = {'list' : fruits,
                            'str_value' : j_str}
        
        #使用するテンプレートを指定
        path = os.path.join(os.path.dirname(__file__), 'template/index.html')
        #レンダリングを実行し、結果をレスポンスとしてブラウザに返却
        self.response.out.write(template.render(path, template_values))

def main():
    application = webapp.WSGIApplication([('/', MainHandler)],
                                       debug=True)
    wsgiref.handlers.CGIHandler().run(application)


if __name__ == '__main__':
    main()
 
アプリケーションの構成はapp.yamlと同階層フォルダにtemplateを作って、その下にindex.htmlテンプレートファイルを作る
template/index.html
app.yaml
index.yaml
main.py
投稿者 時刻: 0 件のコメント:
ラベル: , , ,

Pythonによる開発の有用リンク



○Pythonのライブラリ　PyPI


投稿者 時刻: 0 件のコメント:
ラベル:

2011年7月30日土曜日

ヨミモノ



Web開発の基本など
http://blog.madoro.org/mn/
投稿者 時刻: 0 件のコメント:
ラベル:

プロダクトマネージメント(3) -プロダクトマネジメント VS. プロジェクトマネジメント-

"Inspired日本語版 第3章　プロダクトマネジメント VS. プロジェクトマネジメント"より


パッケージソフトの世界では、製品はすべての機能を内蔵してパッケージにされ、一度パッケージがリリースされると、次がリリース されるまでに数ヶ月、場合によっては数年かかる。だから、製品とプロジェクトは、一般的に作業の精度や頻度の点で一致していて、プロダクトマネージャーが プロジェクトマネージャーを兼ねることが比較的容易

多くのインターネットサービス企業は、大きな共通のコードベースに対して小規模な改良をこまめにやる必要がある。典型的なプロジェク トは、次のリリース（だいたい週単位から月単位）までに間に合わないほど大量の作業が必要となったので、並行して複数の開発プロジェクトを進めたり、改良 版のリリースにトレインモデルを採用したりするようになった。ほとんどのインターネット企業は、スタートアップ段階を終えてもこのトレインモデルを使って いる。

トレインでは、多くのプロジェクトやプロジェクトマネージャーの諸事情を踏まえた上で、リリース管理、エンジニアリング、サイト運用、顧客サービス、プロダクトマネジメントといった重要な調整をやらなければならない。



○すばらしいプロジェクトマネージャーが備えている７つのスキル

緊迫感　歩いて入ってくるだけで、中はたちまち緊迫感が流れる

立案者たれ　問題を明確かつ簡潔に特定して整理し、建設的な会議を運営する

明晰な思考力　個々の問題をそれぞれ区別し、感情やしがらみをほぐすことで、根底にある問題を明らかにし、みんなが問題の解決に集中できるようにする

データ指向　意思決定の局面で、プロジェクトマネージャー は、緊迫感を伝え、問題を明確にし、合理的で透明性のある理由付けをして、データに基づいた意思決定をしなければならない。また、プロジェクトマネー ジャーは、チーム内からのデータや意見をいつ集めればよいか、いつ問題を経営陣に上げればよいかを知っておく必要がある。

判断力　いつ他のメンバーのお尻を叩 くのか、いつ経営陣に報告するか、いつ追加情報を集めるか、いつ場所を変えてちょっとプライベートおしゃべりをすればいいか、などを心得ている。こうした 特性については、人から教わるのは難しく、経験がモノを言う。

姿勢　障害をひとつひとつ乗り越えることである。優れたプロジェクトマネージャーは言い訳を しない。やり遂げるのだ。粘り強くて、とどまることを知らない。
投稿者 時刻: 0 件のコメント:
ラベル:

プロダクトマネージメント(1) -プロダクトマネジメントVS. プロダクトマーケティング-

"Inspired日本語版第2章　プロダクトマネジメント VS. プロダクトマーケティング"より


プロダクトマネージャー 作りたい製品を詳細に定義することと、実際のお客様やユーザーとともに製品を検証する

プロダクトマーケティ ング　世界に向けて製品について語ることだ。この任務には、市場における製品の位置づけを明確にすること、製品に関する情報発信、価格設定、新製 品の発売の管理、販売チャネルで製品を売り込むためのツールの提供、そして、オンラインマーケティングや市場関係者に対するマーケティングなどの主要な マーケティング活動を指揮することも含まれる。

○よくある3つの間違い
マーケティング主導の製品である：プロダクトマーケティングマネージャーとかプロダクトマネージャーという肩書 きの人は置かれていて、市場の要請に応えるという任務を負っている。それはよいのだが、詳細な製品要求の決定や製品を「見つけ出す」過程でなされるはずの 難しい判断の多くをすっ飛ばして、いきなり製品開発がエンジニアリングに回されてしまうという状況である。（しかも、よくあることなのだが、ユーザーエク スペリエンスデザインを無視してしまう。この点は、別のトピックで扱う。）

一つの役割に二人の担当者がいる：全社的な観点からビジネス判断をするプロダクトマーケティング担当者と、個別の製品についての判断をするプロダクトマネージャーとの間で、その製品を定義する役割がブ分割されてしまうという状況である。

一人で二つの役割を兼務している：プロダクトマーケティングマネージャーが、プロダクトマネージャーを兼務しなければならない状況である。（この人は、プロダクトマネージャー、プロダクトマーケティング担当などと呼ばれたりする。）
投稿者 時刻: 0 件のコメント:
ラベル:

プロダクトマネージメント(2) -ユーザーエクスペリエンスデザインを理解する-


"Inspired日本語版　第4章　プロダクトマネジメント vs. デザイン "より


○優れたユーザーエクスペリエンスに必要な役割

インタラクションデザイン インタラクションデザイナーの役割は、対象となるユーザーを深く理解し、ユーザーにとって作業効率のいいタスクやナビゲーションやフローを考案することで ある。通常、インタラクションデザイナーは、製品要求をワイヤーフレームという設計図にマッピングし、これをビジュアルデザイナーに手渡す。

ビジュアルデザイン ビジュアルデザイナーの役割は、ワイヤーフレームに肉付けをして、実際のページやユーザーインタフェースの見た目と雰囲気 (正確なレイアウト、色、フォントなど) を創作することである。ここでもっと大事なのは、製品のビジュアルデザインというのは、ユーザーの感情に語りかけたりユーザーの感情を呼び起こしたりす る、ということだ (これは、普通考えられているよりもはるかに重要である)。

ラピッドプロトタイピング これは、プロダクトマネージャーやデザイナーのアイデアを反映したプロトタイプ (試作品) を作っては実際のユーザーでテストする、という作業を繰り返すことである。

ユーザビリティテスト 製品のユーザビリティ (使い勝手) の検証を担当する人は、もっぱらユーザーの調査と分析をやる。製品やそのプロトタイプによって、ユーザーのやりたいことが容易に達成できるのかどうかを判 定するのである。この仕事には、検証に参加してくれるユーザーとして適切な人々を集めること、検証作業を行うこと、検証結果を評価すること、そして代替案 を提示することも含まれる。


次の3つの理由から、インタラクションデザイナーの仕事は外注しない方がいい。
1. 複数のプロジェクトを進める中で、ユーザーや顧客について必要な理解をしっかりと作り上げるのは、時間がかかる。デザインを外注すると、ほとんどの場合、 外注先の業者にはそういう時間はない。もしそれができたとしても、次のリリースの時には、そのユーザーや顧客に関する知識は引き継がれずに失われてしま う。

2. インタラクションデザイナーは、プロジェクトの開始から製品発表までの間ずっと、いつでも動きが取れる態勢でいて、プロジェクトに深く関与する必要があ る。開発や検証の段階では細かい問題が何百も出てくるので、インタラクションデザイナーが常時待機していて、即座に適切な判断を下すことが重要だ。

3. 製品のユーザーエクスペリエンスは、会社にとって製品の核心部分以外の何物でもないので、外部に任せるわけにはいかない。何かを外注するとすれば、品質保証 (QA) あたりがいいだろう。


ビジュアルデザインについては、さまざまな要望に応じてくれる制作会社がたくさんあるので、外注も可能だ。特に、社内に有能なインタラクションデザイナーを抱えているのであれば、ビジュアルデザインは外注でよい。また、ユーザー調査やユーザビリティ検証も外注できる。プロトタイプのコードはすべて使い捨て。
投稿者 時刻: 0 件のコメント:
ラベル:
登録: 投稿 (Atom)

Amazon3